51 ms·

No. > that's why they've killed XUL We couldn't deliver a multiprocess browser without doing it. > about:config for the android version I completely support

No. > that's why they've killed XUL We couldn't deliver a multiprocess browser without doing it. > about:config for the android version I completely supported this and continue to do so. GeckoView on Android works completely differently than desktop Firefox, and about:config's semantics are not identical between the two. A few of us were interested in offering an alternative that gave users a way to make adjustments in a way that was "safe," but as you can imagine that has never been a management priority.

throwaway0x7E6 4y ago
>We couldn't deliver a multiprocess browser without doing it. even if the management understood that advanced extensions were a major factor for choosing Firefox over the alternatives and were willing to dedicate enough time/people/money to tackling the issue?
- dblohm7 4y ago
  Yes. It was an intractable problem.
  - throwaway0x7E6 4y ago
    well, shit. I concede that particular point then. my presumption of malice was primarily based on what followed - crippled android addons, forced addon signing on non-Nightly, upcoming adoption of manifest v3. put together, the poweruser experience we had in 2015 is better than the one we have now. and unlike XUL, the only explanation I see for all of these is either malice or stupidity.
Dylan16807 4y ago
> We couldn't deliver a multiprocess browser without doing it. So uh. What was that whole thing about making all the extensions rewrite their code to support multiprocess? Which many extensions did, putting in huge amounts of work, only to be told shortly after that XUL was going away. https://web.archive.org/web/20191220054834/https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Working_with_multiprocess_Firefox https://web.archive.org/web/20191220054834/https://developer...
pseudalopex 4y ago
> We couldn't deliver a multiprocess browser without doing it. But you did.[1] [1] https://wiki.mozilla.org/Electrolysis#Add-ons_Schedule https://wiki.mozilla.org/Electrolysis#Add-ons_Schedule

throwaway0x7E6 4y ago

>We couldn't deliver a multiprocess browser without doing it. even if the management understood that advanced extensions were a major factor for choosing Firefox over the alternatives and were willing to dedicate enough time/people/money to tackling the issue?

dblohm7 4y ago
Yes. It was an intractable problem.
- throwaway0x7E6 4y ago
  well, shit. I concede that particular point then. my presumption of malice was primarily based on what followed - crippled android addons, forced addon signing on non-Nightly, upcoming adoption of manifest v3. put together, the poweruser experience we had in 2015 is better than the one we have now. and unlike XUL, the only explanation I see for all of these is either malice or stupidity.

Dylan16807 4y ago

> We couldn't deliver a multiprocess browser without doing it. So uh. What was that whole thing about making all the extensions rewrite their code to support multiprocess? Which many extensions did, putting in huge amounts of work, only to be told shortly after that XUL was going away. https://web.archive.org/web/20191220054834/https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Working_with_multiprocess_Firefox https://web.archive.org/web/20191220054834/https://developer...

pseudalopex 4y ago

> We couldn't deliver a multiprocess browser without doing it. But you did.[1] [1] https://wiki.mozilla.org/Electrolysis#Add-ons_Schedule https://wiki.mozilla.org/Electrolysis#Add-ons_Schedule