32 ms·

Extensions is currently the only thing FF is better than the competition at, and they scrap it to copy Chrome APIs... I just can't understand why they would scr

by hucker 10y ago

Extensions is currently the only thing FF is better than the competition at, and they scrap it to copy Chrome APIs... I just can't understand why they would scrap XUL-based extensions before their new APIs reach feature parity. The day pentadactyl stops working is the day I stop using firefox.

laurent123456 10y ago
I can see where they're coming from though. Today, developers need to create two versions of their extensions - one that works on Safari, Chrome and Opera (and Edge?) and one specifically for Firefox. As the market share of Firefox is not that high, maybe extension developers eventually won't be bothered with supporting that extra version, which means Firefox extensions will be less up-to-date and there will be less of them. That's probably a trade off they have to make, though I imagine they're aware that some add-ons won't work and that users will be annoyed by that.
- hucker 10y ago
  That's an argument for providing similar/the same APIs as Chrome et al sure, but not for deprecating the old ones.
  - dmethvin 10y ago
    It's quite a burden to maintain two different sets of APIs.
    - alphapapa 10y ago
      I'm sorry, but I hear this all the time--it's the primary argument used for deprecating or removing any functionality in any software. And my response is: so what? Maintaining software is a burden, period. Software exists to be useful. The APIs in question make it useful. The developers have been maintaining it for nearly 20 years. Their employer receives millions of dollars a year to do so. They don't want to maintain this "burden" anymore because it's not fun to maintain old code. It's not glamorous. No one becomes a rock star by unloading the bus. But if you remove the baggage compartments, the bus ceases to be useful, and the show doesn't go on. Chromium is such a cooler project. It was started from scratch (except for the WebKit part), and it's made by Google (which at least used to be cool), and it's got all these modern APIs. They're so great that it only took them 7 years to support resumable HTTP requests[1]. Firefox used to be about the users. Now it's about the developers. (This is not to say that individual developers are selfish, but that the organization as a whole is behaving in a way that disregards the needs of users and prioritizes the desires of the developers.) 1: https://bugs.chromium.org/p/chromium/issues/detail?id=7648 https://bugs.chromium.org/p/chromium/issues/detail?id=7648. Just look at this cleverness: "In the absence of a crypto::SecureHash object, DownloadFile reads the partial file and calculates the partial hash state in a new crypto::SecureHash object. If a prefix hash value is available, then the hash of the partial file is matched against this prefix hash. A mismatch causes a FILE_HASH_MISMATCH error which in turn causes the download to abandon its partial state and restart." Any other software in the world would just restart the download. I mean, they already give it a special ".crdownload" extension, so it's not like any other program is going to mess with it. But no, they can't just resume the download, they have to make 15 hash checks and pass around 7 different objects and find every possible reason to start the download all over again. What could have been a 5-line patch turned into 7 years of waiting, a dozen revisions across 50 files...
      - duskwuff 10y ago
        With regard to resumable downloads -- that "cleverness" isn't for the sake of being clever; it's in there to avoid two very common cases where a naïve download resume will corrupt a file: 1. The remote file has changed since the previous download, so "resuming" the download will end up combining two different files. 2. The user's computer crashed during the first download, and some of the data in the partial download was not written to disk properly. (A particularly common case: the last few blocks of the file are zeroed out.)
        noisem4ker 10y ago
        1. Date / file size check. In doubt, ask the user. 2. Rollback a few megabytes. These problems were solved ages ago by most download managers.
        alphapapa 10y ago
        Indeed, this was already proposed on the bug tracker, but the Chromium developers ignored it: https://bugs.chromium.org/p/chromium/issues/detail?id=7648#c72 https://bugs.chromium.org/p/chromium/issues/detail?id=7648#c...
  - Manishearth 10y ago
    It's not the same APIs as chrome though. It's the same base. The Firefox APIs are planned to be a superset of the Chrome ones (so you have some compatibility there), but will provide the functionality exposed by many of the older APIs.
- Endy 10y ago
  Then stop developing free software for Google. Be Firefox and/or Pale Moon exclusive. Problem solved.
emptyfile 10y ago
Lunacy
Yoric 10y ago
Well, XUL-based extensions are not scraped yet. They will, at some point in 2017, but we're not there yet. The reason to scrape them is simple: the total API surface of XUL-based extensions is pretty much all of the internal APIs of Firefox, which means that any change anywhere in the code of Firefox breaks some extension accidentally. That's a compatibility burden that Mozilla could afford when the only competitor was IE, but it makes the development of Firefox much less nimble than that of Chrome & co. So a new, less invasive and more future-proof API is sorely needed.
- nathancahill 10y ago
  Surely the burden is on the extension developers and not Mozilla?
  - Yoric 10y ago
    As a Firefox developer, whenever I make a change (and I mean pretty much any change to an API accessible through platform JS), I have two choices: 1/ either try and locate all the add-ons that will be broken, get in touch with their developers, be ignored by most of them, start several weeks of negotiation with those who do answer, then eventually, several months after my code is ready, land the change, and notice that Chrome has landed that same change a few months ago; 2/ ignore the add-on developers, improve Firefox immediately, but certainly break some add-ons, hence breaking the user experience of millions of users for no understandable reason. As you can imagine, neither solution is good and everybody suffers from either. WebExtensions condense all the instances of 1/ into a single point of time, hoping that we never again need to go through this painful dance.
    - deleted 10y ago
      [deleted]
    - ethbro 10y ago
      Is there a reason a both approach wasn't pursued with the current method being marked unsafe but still available for use? A la Rust mixing code but having to explicitly mark unsafe bits. For reasons listed in other comments above, the "we will expand WebExtensions API coverage based on current add-on needs" scares the shit out of me. I'm having visions of why I quit using Chrome because there was some download UX that could not be altered, and the default Google "one true way" of doing it irked the hell out of me.
jvehent 10y ago
pentadactyl is co-developed by a member of the Firefox Add-ons core team [1]. I don't know what the plan is to port it to web extensions, but at least you can be sure the team is aware of it ;) [1] https://github.com/5digits/dactyl/graphs/contributors https://github.com/5digits/dactyl/graphs/contributors
alphapapa 10y ago
> The day pentadactyl stops working is the day I stop using firefox. I'm with you. We should start moving to Pale Moon before the end comes.
dri_ft 10y ago
Didn't Pentadactyl stop working a while ago? For a while I was trying to keep it working, making the necessary changes on every firefox update, but eventually it got too much for me and I switched over to VimFX. At first I didn't think it would be satisfactory, but it actually is a quite good 80% solution. What seemed to be a weakness - the fact that it doesn't aggressively change how the browser works - now seems like a good design decision, making it considerably more robust than Pentadactyl/Vimperator in the face of the changes Mozilla is making, even at the cost of some of Pentadactyl/Vimperator's more advanced functionality.
- hucker 10y ago
  Apart from having to manually up the maxVersion every now and then (and rebuilding from source), pentadactyl has Just Worked™ for me.
eitland 10y ago
One of them answered here and IIRC what (s)he said was that they won't cut off the old APIs until every popular extension can be upgraded to the new api. So it was less of providing a poor api like Chrome and more like creating a newer and better API that also happens to be a superset of Chromes API.
teh 10y ago
I just migrated a complex extension and with Firefox 52 most features are there. It was a bit painful but the new API is much better IMO. Also, we now have one code base less to maintain.
- nachtigall 10y ago
  Interesting. Mind sharing a link to your add-on?

by hucker 10y ago

laurent123456 10y ago

I can see where they're coming from though. Today, developers need to create two versions of their extensions - one that works on Safari, Chrome and Opera (and Edge?) and one specifically for Firefox. As the market share of Firefox is not that high, maybe extension developers eventually won't be bothered with supporting that extra version, which means Firefox extensions will be less up-to-date and there will be less of them. That's probably a trade off they have to make, though I imagine they're aware that some add-ons won't work and that users will be annoyed by that.

hucker 10y ago
That's an argument for providing similar/the same APIs as Chrome et al sure, but not for deprecating the old ones.
- dmethvin 10y ago
  It's quite a burden to maintain two different sets of APIs.
  - alphapapa 10y ago
    I'm sorry, but I hear this all the time--it's the primary argument used for deprecating or removing any functionality in any software. And my response is: so what? Maintaining software is a burden, period. Software exists to be useful. The APIs in question make it useful. The developers have been maintaining it for nearly 20 years. Their employer receives millions of dollars a year to do so. They don't want to maintain this "burden" anymore because it's not fun to maintain old code. It's not glamorous. No one becomes a rock star by unloading the bus. But if you remove the baggage compartments, the bus ceases to be useful, and the show doesn't go on. Chromium is such a cooler project. It was started from scratch (except for the WebKit part), and it's made by Google (which at least used to be cool), and it's got all these modern APIs. They're so great that it only took them 7 years to support resumable HTTP requests[1]. Firefox used to be about the users. Now it's about the developers. (This is not to say that individual developers are selfish, but that the organization as a whole is behaving in a way that disregards the needs of users and prioritizes the desires of the developers.) 1: https://bugs.chromium.org/p/chromium/issues/detail?id=7648 https://bugs.chromium.org/p/chromium/issues/detail?id=7648. Just look at this cleverness: "In the absence of a crypto::SecureHash object, DownloadFile reads the partial file and calculates the partial hash state in a new crypto::SecureHash object. If a prefix hash value is available, then the hash of the partial file is matched against this prefix hash. A mismatch causes a FILE_HASH_MISMATCH error which in turn causes the download to abandon its partial state and restart." Any other software in the world would just restart the download. I mean, they already give it a special ".crdownload" extension, so it's not like any other program is going to mess with it. But no, they can't just resume the download, they have to make 15 hash checks and pass around 7 different objects and find every possible reason to start the download all over again. What could have been a 5-line patch turned into 7 years of waiting, a dozen revisions across 50 files...
    - duskwuff 10y ago
      With regard to resumable downloads -- that "cleverness" isn't for the sake of being clever; it's in there to avoid two very common cases where a naïve download resume will corrupt a file: 1. The remote file has changed since the previous download, so "resuming" the download will end up combining two different files. 2. The user's computer crashed during the first download, and some of the data in the partial download was not written to disk properly. (A particularly common case: the last few blocks of the file are zeroed out.)
      - noisem4ker 10y ago
        1. Date / file size check. In doubt, ask the user. 2. Rollback a few megabytes. These problems were solved ages ago by most download managers.
        alphapapa 10y ago
        Indeed, this was already proposed on the bug tracker, but the Chromium developers ignored it: https://bugs.chromium.org/p/chromium/issues/detail?id=7648#c72 https://bugs.chromium.org/p/chromium/issues/detail?id=7648#c...
- Manishearth 10y ago
  It's not the same APIs as chrome though. It's the same base. The Firefox APIs are planned to be a superset of the Chrome ones (so you have some compatibility there), but will provide the functionality exposed by many of the older APIs.
Endy 10y ago
Then stop developing free software for Google. Be Firefox and/or Pale Moon exclusive. Problem solved.

emptyfile 10y ago

Lunacy

Yoric 10y ago

Well, XUL-based extensions are not scraped yet. They will, at some point in 2017, but we're not there yet. The reason to scrape them is simple: the total API surface of XUL-based extensions is pretty much all of the internal APIs of Firefox, which means that any change anywhere in the code of Firefox breaks some extension accidentally. That's a compatibility burden that Mozilla could afford when the only competitor was IE, but it makes the development of Firefox much less nimble than that of Chrome & co. So a new, less invasive and more future-proof API is sorely needed.

nathancahill 10y ago
Surely the burden is on the extension developers and not Mozilla?
- Yoric 10y ago
  As a Firefox developer, whenever I make a change (and I mean pretty much any change to an API accessible through platform JS), I have two choices: 1/ either try and locate all the add-ons that will be broken, get in touch with their developers, be ignored by most of them, start several weeks of negotiation with those who do answer, then eventually, several months after my code is ready, land the change, and notice that Chrome has landed that same change a few months ago; 2/ ignore the add-on developers, improve Firefox immediately, but certainly break some add-ons, hence breaking the user experience of millions of users for no understandable reason. As you can imagine, neither solution is good and everybody suffers from either. WebExtensions condense all the instances of 1/ into a single point of time, hoping that we never again need to go through this painful dance.
  - deleted 10y ago
    [deleted]
  - ethbro 10y ago
    Is there a reason a both approach wasn't pursued with the current method being marked unsafe but still available for use? A la Rust mixing code but having to explicitly mark unsafe bits. For reasons listed in other comments above, the "we will expand WebExtensions API coverage based on current add-on needs" scares the shit out of me. I'm having visions of why I quit using Chrome because there was some download UX that could not be altered, and the default Google "one true way" of doing it irked the hell out of me.

jvehent 10y ago

pentadactyl is co-developed by a member of the Firefox Add-ons core team [1]. I don't know what the plan is to port it to web extensions, but at least you can be sure the team is aware of it ;) [1] https://github.com/5digits/dactyl/graphs/contributors https://github.com/5digits/dactyl/graphs/contributors

alphapapa 10y ago

> The day pentadactyl stops working is the day I stop using firefox. I'm with you. We should start moving to Pale Moon before the end comes.

dri_ft 10y ago

Didn't Pentadactyl stop working a while ago? For a while I was trying to keep it working, making the necessary changes on every firefox update, but eventually it got too much for me and I switched over to VimFX. At first I didn't think it would be satisfactory, but it actually is a quite good 80% solution. What seemed to be a weakness - the fact that it doesn't aggressively change how the browser works - now seems like a good design decision, making it considerably more robust than Pentadactyl/Vimperator in the face of the changes Mozilla is making, even at the cost of some of Pentadactyl/Vimperator's more advanced functionality.

hucker 10y ago
Apart from having to manually up the maxVersion every now and then (and rebuilding from source), pentadactyl has Just Worked™ for me.

eitland 10y ago

One of them answered here and IIRC what (s)he said was that they won't cut off the old APIs until every popular extension can be upgraded to the new api. So it was less of providing a poor api like Chrome and more like creating a newer and better API that also happens to be a superset of Chromes API.

teh 10y ago

I just migrated a complex extension and with Firefox 52 most features are there. It was a bit painful but the new API is much better IMO. Also, we now have one code base less to maintain.

nachtigall 10y ago
Interesting. Mind sharing a link to your add-on?