4 ms·

I think your comment is a much more salient criticism. In many ways, webExtensions could be a more accessible system than XUL addons if there was a serious eff

I think your comment is a much more salient criticism. In many ways, webExtensions could be a more accessible system than XUL addons if there was a serious effort to give the end-user more tools to use them. I honestly really like the overall architecture of webExtensions, and I like the idea of having more core code in modern Javascript. But there's a lot of weirdness around the ecosystem itself that makes building extensions into a chore. There's a theoretical set of changes Firefox could make that would turn webExtensions into an extremely accessible, powerful user-facing feature for on-the-fly customizing and inspecting what their browser was doing. And I don't think it would need to be that inherently less secure. It would need to approach security differently, but I feel like many of these are solvable problems, and many of the changes required (better sandboxing, active tab permissions) are stuff we want for extensions today anyway. Some of the changes that came out of dropping XUL are really good. A lot of Firefox's styling is handled through CSS now. That should be a huge accessibility win for new users, and it should provide a nice gateway for new users to think more about moving on to making their own websites using the same technology. Except... userChrome.css is hidden in a config directory somewhere and not loaded by default[0]. They built a really nice way for users to quickly add minor styling customizations, and then they hid it from end users. [0]: https://www.userchrome.org/how-create-userchrome-css.html https://www.userchrome.org/how-create-userchrome-css.html

dman 6y ago
Sure - I can see that if we do arrive at a future where all of Firefox chrome is implemented via a HTML/CSS itself and it sits on top of a standardized core that exposes well documented APIs (which both end users and Firefox developers) can use for feature development - then yes we will be back to the world where someone outside Mozilla could build something like Komodo IDE on top of Mozilla tech. One question I have as a user - what is an acceptable grace period for coming up with an equivalent replacement when you take an API away? Even the CSS styling not being loaded by default that you pointed out suggests that Firefox devs appear to view extensibility as something that they have to support cautiously and grudgingly. There is a chicken and egg problem here - if you make it harder to develop, build and ship non trivial extensions to end users then only a tiny fraction of users will use them. Then you will use the lack of usage of these extensibility features to deprioritize the development efforts that go into them. I would really like someone to take on the task of building a "Workstation" browser - built for power users.
- danShumway 6y ago
  > There is a chicken and egg problem here - if you make it harder to develop, build and ship non trivial extensions to end users then only a tiny fraction of users will use them. This is a really good point. > what is an acceptable grace period for coming up with an equivalent replacement when you take an API away? I really don't know. I am frustrated with the current state of extensions in Firefox, even as I acknowledge that the situation in Firefox is still way better than it is in browsers like Chrome or Safari, and even as I remain hopeful that the Firefox extension ecosystem could be really good. I am sympathetic to the argument that it's an engineering resources problem. But, that also makes me really nervous about the Mozilla cuts that happened recently, because now how long are we going to wait for Servo to be in a usable state, if it even ever gets to a usable state? Like you mention above, when you're forging a new trail in an underdeveloped area and making a case that users would benefit from these features if the ecosystem supported them enough and trained users to use them, you need some freedom to be flexible and experimental and to waste some resources forging that trail. And if resources are as scarce as Mozilla is claiming, then what are the features that are going to be cut first? The experimental, trailblazing ones, the weird ideas like, "shouldn't there be a section in the Firefox options where users can just live-edit the CSS to the browser?".
  - dman 6y ago
    So I will concede that it is time to bury all the XUL/XPCom misgivings. We now need to rededicate ourselves to the same extensible vision using the new stack.
    - danShumway 6y ago
      I think we need some kind of champion to make that point -- to prove that the extensible vision we did have and lost is still worth pursuing. But that's not really a useful thing for me to say, because I have no idea where we can go to get that champion, and I'm at least low-key worried about Mozilla's ability and willingness to be that champion. But agreed. I think it's about more than just XUL vs webExtensions, I think it's a broad tech/cultural issue about making the case that end-user-accessible control and customization is important.

dman 6y ago

Sure - I can see that if we do arrive at a future where all of Firefox chrome is implemented via a HTML/CSS itself and it sits on top of a standardized core that exposes well documented APIs (which both end users and Firefox developers) can use for feature development - then yes we will be back to the world where someone outside Mozilla could build something like Komodo IDE on top of Mozilla tech. One question I have as a user - what is an acceptable grace period for coming up with an equivalent replacement when you take an API away? Even the CSS styling not being loaded by default that you pointed out suggests that Firefox devs appear to view extensibility as something that they have to support cautiously and grudgingly. There is a chicken and egg problem here - if you make it harder to develop, build and ship non trivial extensions to end users then only a tiny fraction of users will use them. Then you will use the lack of usage of these extensibility features to deprioritize the development efforts that go into them. I would really like someone to take on the task of building a "Workstation" browser - built for power users.

danShumway 6y ago
> There is a chicken and egg problem here - if you make it harder to develop, build and ship non trivial extensions to end users then only a tiny fraction of users will use them. This is a really good point. > what is an acceptable grace period for coming up with an equivalent replacement when you take an API away? I really don't know. I am frustrated with the current state of extensions in Firefox, even as I acknowledge that the situation in Firefox is still way better than it is in browsers like Chrome or Safari, and even as I remain hopeful that the Firefox extension ecosystem could be really good. I am sympathetic to the argument that it's an engineering resources problem. But, that also makes me really nervous about the Mozilla cuts that happened recently, because now how long are we going to wait for Servo to be in a usable state, if it even ever gets to a usable state? Like you mention above, when you're forging a new trail in an underdeveloped area and making a case that users would benefit from these features if the ecosystem supported them enough and trained users to use them, you need some freedom to be flexible and experimental and to waste some resources forging that trail. And if resources are as scarce as Mozilla is claiming, then what are the features that are going to be cut first? The experimental, trailblazing ones, the weird ideas like, "shouldn't there be a section in the Firefox options where users can just live-edit the CSS to the browser?".
- dman 6y ago
  So I will concede that it is time to bury all the XUL/XPCom misgivings. We now need to rededicate ourselves to the same extensible vision using the new stack.
  - danShumway 6y ago
    I think we need some kind of champion to make that point -- to prove that the extensible vision we did have and lost is still worth pursuing. But that's not really a useful thing for me to say, because I have no idea where we can go to get that champion, and I'm at least low-key worried about Mozilla's ability and willingness to be that champion. But agreed. I think it's about more than just XUL vs webExtensions, I think it's a broad tech/cultural issue about making the case that end-user-accessible control and customization is important.