Attempting to define XUL removal

[Brian Grinstead]

Removing XUL has been talked about for a long time, but I think it means different things to different people. Since I’ve spent some time working on XUL-related projects I’m going to summarize what it means to me as a way to share what’s currently planned and to get feedback.

XUL is a collection of technologies, so there isn’t going to be a single project that “removes XUL”. What we’d like to do is align browser chrome development more closely with web development, and to simplify Gecko by focusing on the web platform. Each of the projects below should get us a step closer to that, and each has its own priority and timeline.

One of the successes of XUL is that some of the good parts are now part of the web platform. For those features, “removal” looks like a migration to the standard. Once the old feature isn’t used anymore in chrome, we intend to remove the platform feature (and may remove parts of it along the way as those parts become unused).

• XBL bindings can be replaced with ‘webbier' alternatives like Web Components or plain JS. It’s a large project, and we are actively working on removing bindings from the frontend and supporting Web Components in the platform (metabug, tracking dashboard).
• XUL flexbox can now be emulated as CSS flexbox. You can try `./mach run --setpref layout.css.emulate-moz-box-with-flex=true` to see how it looks. The main work to do now is to improve performance on CSS flexbox to get to parity on the TART test. That perf work is mostly unassigned - if you’d like to help with this project please get in touch or take a look at the perf metabug (emulation metabug, perf metabug).

Other features will be removed and not replaced:

• XUL Overlays are no longer necessary for supporting XUL addons and we can simplify a bunch of things by moving away from them. This is actively being worked on, and we expect to be able to remove platform support in a matter of weeks (metabug).
• XUL Templates were removed at the beginning of 2018. There was only one consumer on the frontend which got replaced with simpler JS, and the platform support (around 40K LOC) was removed as well (bug).

There is another set of features in XUL that aren’t part of the web platform but also provide functionality that can’t be removed without a replacement that works in chrome HTML. For example:

• Localization via external DTD files. There are a bunch of reasons why we are transitioning the localization infrastructure to use Project Fluent, including that DTDs are tied to the XML parser and can’t be used from HTML. This work is actively happening, currently focused on strings in about:preferences but planned to expand across the browser chrome in coming quarters (metabug, fluent homepage).

• Generating native menus and popups. This is in the planning phase.
• Supporting special tags like <browser> and <tree> (and many more). This is in the planning phase.
• Extra features that make the application tick, like XULStore and fastload. This is in the planning phase.

Much of that work is still being planned, so there aren’t a lot of specifics to report. Features that are blocking the ability to load a top-level HTML window, or that are blocking other work like XBL removal will get prioritized above others.

Thanks,

Brian

[ExE Boss]

Quoting the comment I posted on Reddit:

Native menus and popups could probably be implemented with the <menu type="toolbar"> (See bug 746087), <button type="menu"> (See bug 1241353) and <menu type="context"> HTML5 features, even though the last one is deprecated, so it could potentially be restricted to chrome code only.

​

Virus-free. www.avast.com

[Brian Grinstead]

Yeah, if we can implement the HTML spec for menus and context menus that would nice as opposed to coming up with something new (even if certain features are only enabled in chrome). Will have to look closer at the spec but from the MDN page it looks like the markup maps pretty closely to the xul menu markup.

Brian

> On Mar 21, 2018, at 4:31 PM, ExE Boss <e735...@opayq.com> wrote:
>
> Quoting the comment I posted on Reddit:
>
> Native menus and popups could probably be implemented with the <menu type="toolbar"> (See bug 746087), <button type="menu"> (See bug 1241353) and <menu type="context"> HTML5 features, even though the last one is deprecated, so it could potentially be restricted to chrome code only.
>
>

> Virus-free. www.avast.com
> _______________________________________________
> firefox-dev mailing list
> firef...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev

_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev

[Alex Vincent]

Please tell me if the --app command line argument is slated for removal as well.  Our business currently depends on this legacy feature of XULRunner.

Alex Vincent

FileThis, Inc.

--

"The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001