4 ms·

The code that changes the look is entirely CSS. What’s stopping FF from allowing this level of theming from normal addons?

chrismorgan 5y ago
The browser’s UI is currently implementation detail: they can change structures, markup, &c. as they desire. If they allow add-ons to apply arbitrary CSS to the chrome, they can’t change it any more. Perhaps they could operate a selector whitelist or something like that, but it’d subsequently limit what they could do when they wanted or needed to change things. This was basically the problem with old-style XUL addons; they prevented the browser from improving, actively hindering in important areas like performance and security (by which I mean security of the browser itself even with no extensions—architectural things like sandboxing and going multiprocess), and so eventually they were done away with because they just kept on causing trouble. And that’ only considering the practical problems of allowing this. The security implications of allowing it are rather significant too: a malicious add-on could almost completely conceal its existence, preventing you from removing it.
- shawnz 5y ago
  I agree it was a good idea to get rid of the XUL-based UI and XUL addons. But I think allowing addons to apply some limited CSS changes to the new UI could be a good compromise. It would be significantly less powerful than what could be done with XUL, but it would provide a more reasonable interface to go beyond simply changing colours and background images. I can acknowledge that there would be challenges creating such a feature in a way that is resistant to abuse, but I think it could allow the browser to regain a big competitive advantage at a fraction of the cost of the old implementation.
- rob74 5y ago
  Not that Mozilla has ever really cared a lot to maintain backwards compatibility for the APIs that are public. Maybe it has improved in the last years, but some years ago I developed an extension which didn't need a lot of updates for its actual functionality, but I had to revisit it time and time again just so it would still work with the newest Firefox version...
  - chrismorgan 5y ago
    And that showed the problem of the XUL approach: when everything is public interface, nothing is stable. WebExtensions, on the other hand, has a carefully-defined API with much more dependable stability guarantees.

chrismorgan 5y ago

The browser’s UI is currently implementation detail: they can change structures, markup, &c. as they desire. If they allow add-ons to apply arbitrary CSS to the chrome, they can’t change it any more. Perhaps they could operate a selector whitelist or something like that, but it’d subsequently limit what they could do when they wanted or needed to change things. This was basically the problem with old-style XUL addons; they prevented the browser from improving, actively hindering in important areas like performance and security (by which I mean security of the browser itself even with no extensions—architectural things like sandboxing and going multiprocess), and so eventually they were done away with because they just kept on causing trouble. And that’ only considering the practical problems of allowing this. The security implications of allowing it are rather significant too: a malicious add-on could almost completely conceal its existence, preventing you from removing it.

shawnz 5y ago
I agree it was a good idea to get rid of the XUL-based UI and XUL addons. But I think allowing addons to apply some limited CSS changes to the new UI could be a good compromise. It would be significantly less powerful than what could be done with XUL, but it would provide a more reasonable interface to go beyond simply changing colours and background images. I can acknowledge that there would be challenges creating such a feature in a way that is resistant to abuse, but I think it could allow the browser to regain a big competitive advantage at a fraction of the cost of the old implementation.
rob74 5y ago
Not that Mozilla has ever really cared a lot to maintain backwards compatibility for the APIs that are public. Maybe it has improved in the last years, but some years ago I developed an extension which didn't need a lot of updates for its actual functionality, but I had to revisit it time and time again just so it would still work with the newest Firefox version...
- chrismorgan 5y ago
  And that showed the problem of the XUL approach: when everything is public interface, nothing is stable. WebExtensions, on the other hand, has a carefully-defined API with much more dependable stability guarantees.