4 ms·

Most legacy extensions should already be broken on Nightly, are they not? They've refactored tons of code under the hood, basically all the changes that they'v

by Sylos 9y ago

Most legacy extensions should already be broken on Nightly, are they not? They've refactored tons of code under the hood, basically all the changes that they've wanted to do for years but couldn't do, because it would have broken too many extensions over and over. We're also talking about all the performance improvements that were made since Firefox 48. The majority of legacy extensions are not multiprocess-compatible and they would not have rolled out multiprocess in 48, if they wouldn't have known those multiprocess-incompatible extensions to be deprecated now with 57. Otherwise AMO would have basically been reverse Russian Roulette, where only roughly 1 out of 6 extensions will not kill your performance.

kevincox 9y ago
> Most legacy extensions should already be broken on Nightly, are they not? Yes, a lot would be. However if they could still be used many of them would have been fixed by now. > The majority of legacy extensions are not multiprocess-compatible Yet many are. My point is basically that I would like if FF supported the legacy "API" and left the community to manage fixing things that were broken. I would take this work over not being able to have some extensions any day.
- Sylos 9y ago
  I can understand your point of view, but I do think it is very much necessary to cut things off completely. Otherwise you'd have tons of extensions that could be rewritten as WebExtensions but aren't, because it's less work in the short-term to just fix them for the XUL changes. In the long-term, however, it would be a lot more work, especially if Mozilla starts recklessly breaking things. Similarly, many unmaintained extensions will disappear and WebExtensions will be written to replace them. Those will almost certainly have better quality and performance. Shouldn't be all too hard to pull off for an unmaintained extension. And then there's also stories like with NoScript's transition, which very much is a lot of work, but it will leave the NoScript maintainer with a much cleaner code base, not just from the WebExtension API being cleaner, but also simply because he rearchitectured the whole thing, as he was forced to rewrite anyways. And he'll get significantly better performance out of this, too. He would not have done a rewrite without this, but he's glad that he did it.
  - kevincox 9y ago
    I see the desire to move most extensions. One hope I have is that the next release will roll back some restrictions once active extensions have been ported. However even if the WebExtensions had an "escape hatch" to browser internals it would still require significant porting effort and the promise of being marked as "Full Browser Access" and "Likely to Break" would probably convince everyone who can to port anyways.

by Sylos 9y ago

kevincox 9y ago

> Most legacy extensions should already be broken on Nightly, are they not? Yes, a lot would be. However if they could still be used many of them would have been fixed by now. > The majority of legacy extensions are not multiprocess-compatible Yet many are. My point is basically that I would like if FF supported the legacy "API" and left the community to manage fixing things that were broken. I would take this work over not being able to have some extensions any day.

Sylos 9y ago
I can understand your point of view, but I do think it is very much necessary to cut things off completely. Otherwise you'd have tons of extensions that could be rewritten as WebExtensions but aren't, because it's less work in the short-term to just fix them for the XUL changes. In the long-term, however, it would be a lot more work, especially if Mozilla starts recklessly breaking things. Similarly, many unmaintained extensions will disappear and WebExtensions will be written to replace them. Those will almost certainly have better quality and performance. Shouldn't be all too hard to pull off for an unmaintained extension. And then there's also stories like with NoScript's transition, which very much is a lot of work, but it will leave the NoScript maintainer with a much cleaner code base, not just from the WebExtension API being cleaner, but also simply because he rearchitectured the whole thing, as he was forced to rewrite anyways. And he'll get significantly better performance out of this, too. He would not have done a rewrite without this, but he's glad that he did it.
- kevincox 9y ago
  I see the desire to move most extensions. One hope I have is that the next release will roll back some restrictions once active extensions have been ported. However even if the WebExtensions had an "escape hatch" to browser internals it would still require significant porting effort and the promise of being marked as "Full Browser Access" and "Likely to Break" would probably convince everyone who can to port anyways.