6 ms·

This includes a call for help on Photon, the "new user interface." "Since the UI is written in major parts in JavaScript and CSS and an HTML-like language call

This includes a call for help on Photon, the "new user interface." "Since the UI is written in major parts in JavaScript and CSS and an HTML-like language called XUL, anyone with webdev skills can improve it!" I thought 57 was dumping XUL completely. Wasn't that a major point of 57?

throwaway2048 9y ago
XUL is still there, and there are no immediate plans to get rid of it. Mozilla has just decided that you dont get to use it anymore, the deadline is purely an administrative decision. Its great to see they are going to drive firefox off a cliff with yet another anti-user decision. The situation with popular extensions has improved, but there is going to be a lot of pain, especially with XUL functionality that they refuse to implement in WebExtensions. https://arewewebextensionsyet.com/ https://arewewebextensionsyet.com/
- brighteyes 9y ago
  > XUL is still there, and there are no immediate plans to get rid of it It's true it's still there, but I think the plan is using it less and less. No new UIs are written in it and many things have been rewritten from XUL to HTML5. Eventually it could be removed entirely.
  - throwaway2048 9y ago
    longer term that is sensible sure, but the ecosystem is not ready for it. Its amusing to me that mozilla expects everyone else to be moved off XUL, but not their own code because it has legitimate reasons....
    - angelsl 9y ago
      They are moving everyone else off so they themselves can move off XUL.
- adrianN 9y ago
  It is my understanding that getting rid of XUL in favor of a less peculiar way to do UI is a necessary step to improve security and performance and get rid of a lot of legacy ballast that keeps Firefox from getting better. So there are some upsides to the transition. Time will tell whether it will be a success or whether it will "drive Firefox off a cliff". I don't think you can say a priori what the result will be.
  - throwaway2048 9y ago
    I think you can say a priori, that a major remaining reason to use firefox over chrome is about to be eliminated. Hilariously, dispite the pro-privacy stance mozilla pretends at, they want to start tracking urls visited https://news.ycombinator.com/item?id=15071492 https://news.ycombinator.com/item?id=15071492 Why keep using firefox? Because I love Mozilla so much when they clearly have zero interest in my needs as a user?
- 482794793792894 9y ago
  The UI toolkit "XUL" is something different from the extension API "XUL/XPCOM". And no, it's certainly not just an administrative deadline. For now, you can still tell Firefox Nightly to install legacy extensions, the vast majority of them are just by now completely broken, because Mozilla is ripping out all of that legacy code and refactoring what's left. Here's a list of all of the things that they can get rid of: https://bugzilla.mozilla.org/show_bug.cgi?id=1347507 https://bugzilla.mozilla.org/show_bug.cgi?id=1347507
- chr1 9y ago
  The question is not about "XUL functionality" specifically, XUL is just an implementation detail, and html could work in its place just as well. The question is how much the extensions can do, in the old model they could do anything firefox code could do, in WebExtensions model, they can do only very limited set of things. On one hand it is quite sad to see firefox extensions go, on the other hand the old model was a maintenance hell both for firefox developers and for addon developers, because smallest changes in firefox ui were breaking bunch of addons, and even changes in addons themselves were breaking other addons, which all had incompatibilities and had to do lots of subtle hacks to work together. I have worked on firefox addons for several years, and had to quit firefox when they started ignoring addons and investing in old addon sdk. But saying Mozilla is intentionally killing firefox is not fair the whole thing was shaky and full of hacks and would crumble by itself too. What they should do now, is splitting their ui from the engine, so that advanced users can hack on the ui and get all the benefits of old addon system without the mess. If they fail to do that brave browser with https://github.com/brave/muon https://github.com/brave/muon will take that niche.
ChrisSD 9y ago
The eventually goal is to fully dump XUL but that's going to take time to finish. The major point of 57 is legacy addons will no longer be supported. Think about it this way: the transition away from XUL means the UI code (and more) is going to be very unstable for awhile. Thus addon authors would need to be continually rewriting their code for each update to keep up with the changes. It's better to bite the bullet now and switch to a more stable api.
- throwaway2048 9y ago
  They are not transitioning away from XUL
  - ksec 9y ago
    Are they not ? I thought that was the long term goal. https://github.com/browserhtml/browserhtml https://github.com/browserhtml/browserhtml
  - ChrisSD 9y ago
    Source? Last I heard from Moz, XUL was considered a maintenance burden that increasingly suffers from neglect. HTML now does a comparable job, is standardised, is widely used and needs to be implemented anyway. Maintaining two interface languages doesn't make much sense in the long term.
    - deleted 9y ago
      [deleted]
    - 482794793792894 9y ago
      The XUL/XPCOM extension API is a massive maintenance burden. The XUL UI toolkit is something different and while it's not either magically free of maintenance cost, it's much less of a maintenance burden than the XUL/XPCOM extension API.
      - chr1 9y ago
        XUL is the same XUL both in extensions and in browser ui. XPCOM is another independent technology https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM. They are disabling the direct access from extensions to apis used by browser itself (that is access to XUL _and_ XPCOM), to be able to modify the browser ui without worrying about breaking extensions, with the goal to remove XUL eventually.
TazeTSchnitzel 9y ago
Surely Photon would use HTML, given it's new code?
- 482794793792894 9y ago
  Nope. It uses XUL. It is in some parts new code, but not completely. If you were using Firefox Nightly, you could actually see them slowly changing Australis over to Photon.
482794793792894 9y ago
It's dumping the so-called "XUL/XPCOM extensions", so that's an extension API. The UI toolkit XUL, they'll continue to use. There are some long-term investigations into using HTML/JS/CSS for the UI [1], but for the moment, the performance difference is still too much. [1]: https://github.com/browserhtml/browserhtml https://github.com/browserhtml/browserhtml
- btrask 9y ago
  Why is HTML slower than XUL? I thought XUL was pretty much just a weird version of HTML, possibly with more native toolkit support. Is it because XUL is being used from C++ rather than JS? (I checked the browser.html issue tracker but most of their perf bugs seemed to be resolved.)
  - MBCook 9y ago
    It may also be that XUL is more restrictive or less forgiving. By not having to handle as many edge cases they can skip a lot of code and speed things up. This is just a guess on my part.
  - Yoric 9y ago
    I remember, for instance, that XUL was highly optimized to not create DOM nodes for huge/infinite lists/trees/... Last time I heard about someone attempting to implement these optimizations with comparable APIs in HTML5, the results were ok, but not nearly as good. That was a few years ago, results may be obsolete, of course.
    - fabrice_d 9y ago
      Ha, the xul tree and it's virtual view... Someone (working now at Apple) wrote a super fast list component in HTML for Firefox OS so this can definitely be done.
    - hendersoon 9y ago
      Not sure which APIs you're referring to, but the Vivaldi browser UI is largely rendered in HTML5 and its performance feels native to me.
mintplant 9y ago
The Browser Architecture team at Mozilla [0] is investigating stripping XUL(/XBL) out of Firefox, among other things, but it's more complex than you might expect. [0] https://github.com/mozilla/firefox-browser-architecture https://github.com/mozilla/firefox-browser-architecture

throwaway2048 9y ago

XUL is still there, and there are no immediate plans to get rid of it. Mozilla has just decided that you dont get to use it anymore, the deadline is purely an administrative decision. Its great to see they are going to drive firefox off a cliff with yet another anti-user decision. The situation with popular extensions has improved, but there is going to be a lot of pain, especially with XUL functionality that they refuse to implement in WebExtensions. https://arewewebextensionsyet.com/ https://arewewebextensionsyet.com/

brighteyes 9y ago
> XUL is still there, and there are no immediate plans to get rid of it It's true it's still there, but I think the plan is using it less and less. No new UIs are written in it and many things have been rewritten from XUL to HTML5. Eventually it could be removed entirely.
- throwaway2048 9y ago
  longer term that is sensible sure, but the ecosystem is not ready for it. Its amusing to me that mozilla expects everyone else to be moved off XUL, but not their own code because it has legitimate reasons....
  - angelsl 9y ago
    They are moving everyone else off so they themselves can move off XUL.
adrianN 9y ago
It is my understanding that getting rid of XUL in favor of a less peculiar way to do UI is a necessary step to improve security and performance and get rid of a lot of legacy ballast that keeps Firefox from getting better. So there are some upsides to the transition. Time will tell whether it will be a success or whether it will "drive Firefox off a cliff". I don't think you can say a priori what the result will be.
- throwaway2048 9y ago
  I think you can say a priori, that a major remaining reason to use firefox over chrome is about to be eliminated. Hilariously, dispite the pro-privacy stance mozilla pretends at, they want to start tracking urls visited https://news.ycombinator.com/item?id=15071492 https://news.ycombinator.com/item?id=15071492 Why keep using firefox? Because I love Mozilla so much when they clearly have zero interest in my needs as a user?
482794793792894 9y ago
The UI toolkit "XUL" is something different from the extension API "XUL/XPCOM". And no, it's certainly not just an administrative deadline. For now, you can still tell Firefox Nightly to install legacy extensions, the vast majority of them are just by now completely broken, because Mozilla is ripping out all of that legacy code and refactoring what's left. Here's a list of all of the things that they can get rid of: https://bugzilla.mozilla.org/show_bug.cgi?id=1347507 https://bugzilla.mozilla.org/show_bug.cgi?id=1347507
chr1 9y ago
The question is not about "XUL functionality" specifically, XUL is just an implementation detail, and html could work in its place just as well. The question is how much the extensions can do, in the old model they could do anything firefox code could do, in WebExtensions model, they can do only very limited set of things. On one hand it is quite sad to see firefox extensions go, on the other hand the old model was a maintenance hell both for firefox developers and for addon developers, because smallest changes in firefox ui were breaking bunch of addons, and even changes in addons themselves were breaking other addons, which all had incompatibilities and had to do lots of subtle hacks to work together. I have worked on firefox addons for several years, and had to quit firefox when they started ignoring addons and investing in old addon sdk. But saying Mozilla is intentionally killing firefox is not fair the whole thing was shaky and full of hacks and would crumble by itself too. What they should do now, is splitting their ui from the engine, so that advanced users can hack on the ui and get all the benefits of old addon system without the mess. If they fail to do that brave browser with https://github.com/brave/muon https://github.com/brave/muon will take that niche.

ChrisSD 9y ago

The eventually goal is to fully dump XUL but that's going to take time to finish. The major point of 57 is legacy addons will no longer be supported. Think about it this way: the transition away from XUL means the UI code (and more) is going to be very unstable for awhile. Thus addon authors would need to be continually rewriting their code for each update to keep up with the changes. It's better to bite the bullet now and switch to a more stable api.

throwaway2048 9y ago
They are not transitioning away from XUL
- ksec 9y ago
  Are they not ? I thought that was the long term goal. https://github.com/browserhtml/browserhtml https://github.com/browserhtml/browserhtml
- ChrisSD 9y ago
  Source? Last I heard from Moz, XUL was considered a maintenance burden that increasingly suffers from neglect. HTML now does a comparable job, is standardised, is widely used and needs to be implemented anyway. Maintaining two interface languages doesn't make much sense in the long term.
  - deleted 9y ago
    [deleted]
  - 482794793792894 9y ago
    The XUL/XPCOM extension API is a massive maintenance burden. The XUL UI toolkit is something different and while it's not either magically free of maintenance cost, it's much less of a maintenance burden than the XUL/XPCOM extension API.
    - chr1 9y ago
      XUL is the same XUL both in extensions and in browser ui. XPCOM is another independent technology https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM. They are disabling the direct access from extensions to apis used by browser itself (that is access to XUL _and_ XPCOM), to be able to modify the browser ui without worrying about breaking extensions, with the goal to remove XUL eventually.

TazeTSchnitzel 9y ago

Surely Photon would use HTML, given it's new code?

482794793792894 9y ago
Nope. It uses XUL. It is in some parts new code, but not completely. If you were using Firefox Nightly, you could actually see them slowly changing Australis over to Photon.

482794793792894 9y ago

It's dumping the so-called "XUL/XPCOM extensions", so that's an extension API. The UI toolkit XUL, they'll continue to use. There are some long-term investigations into using HTML/JS/CSS for the UI [1], but for the moment, the performance difference is still too much. [1]: https://github.com/browserhtml/browserhtml https://github.com/browserhtml/browserhtml

btrask 9y ago
Why is HTML slower than XUL? I thought XUL was pretty much just a weird version of HTML, possibly with more native toolkit support. Is it because XUL is being used from C++ rather than JS? (I checked the browser.html issue tracker but most of their perf bugs seemed to be resolved.)
- MBCook 9y ago
  It may also be that XUL is more restrictive or less forgiving. By not having to handle as many edge cases they can skip a lot of code and speed things up. This is just a guess on my part.
- Yoric 9y ago
  I remember, for instance, that XUL was highly optimized to not create DOM nodes for huge/infinite lists/trees/... Last time I heard about someone attempting to implement these optimizations with comparable APIs in HTML5, the results were ok, but not nearly as good. That was a few years ago, results may be obsolete, of course.
  - fabrice_d 9y ago
    Ha, the xul tree and it's virtual view... Someone (working now at Apple) wrote a super fast list component in HTML for Firefox OS so this can definitely be done.
  - hendersoon 9y ago
    Not sure which APIs you're referring to, but the Vivaldi browser UI is largely rendered in HTML5 and its performance feels native to me.

mintplant 9y ago

The Browser Architecture team at Mozilla [0] is investigating stripping XUL(/XBL) out of Firefox, among other things, but it's more complex than you might expect. [0] https://github.com/mozilla/firefox-browser-architecture https://github.com/mozilla/firefox-browser-architecture