De-XBL Plans

[Dave Townsend]

For some time now we've been talking about moving away from XUL and XBL.
The browser architecture team has been hard at work figuring out how to go
about doing that and we're ready to share the first of our proposals more
widely. We have developed a plan to remove XBL from Firefox. It's been
through a successful design review with some of the key engineers and now
is the time for more comments if you have them. We're planning to start some
of the work this quarter with it really ramping up next quarter.

Take a look at the plan
<https://mozilla.github.io/firefox-browser-architecture/text/0007-xbl-design-review-packet.html>
and let us know what you think. There are a couple of areas where we are
still investigating concerns:

Performance is of key interest, so we're actively doing experiments to
validate that Custom Elements can be as performant as XBL
<https://bugzilla.mozilla.org/show_bug.cgi?id=1387125>.
The plan relies on being able to use Custom Elements in XUL, so we're
working on getting a patch
<https://bugzilla.mozilla.org/show_bug.cgi?id=1404420>for that landed
<https://bugzilla.mozilla.org/show_bug.cgi?id=1404420>.
We have a list of <tree> elements in the product and we're evaluating what
the future is for them.

Are there any other concerns that we're missing?

[Cameron McCormack]

On Sat, Oct 21, 2017, at 01:47 AM, Dave Townsend wrote:
> Are there any other concerns that we're missing?

One thing I'm wondering about is memory usage of the Web Components
implementations of these components compared to the XBL ones.
Specifically for style, XBL has the ability to list the style sheets
that apply to the shadow tree declaratively, and we use that to have
only a single copy of the cascade data in memory (and we do the work of
creating the cascade data only once). If we put <style> elements in the
shadow tree, then we will lose the ability to share the cascade data.
(Unless we do something tricky like check the actual style sheet text
when looking up our cascade data cache.) Happily I think if we stick to
using <link rel=stylesheet>s in the shadow trees, we can make our
existing cascade data cache work here.
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1410578 for getting
<link rel=stylesheet> working in shadow trees and
https://bugzilla.mozilla.org/show_bug.cgi?id=1410579 for the cascade
data cache extension.

[Philipp Kewisch]

On 10/20/17 7:47 PM, Dave Townsend wrote:
> For some time now we've been talking about moving away from XUL and XBL.
> The browser architecture team has been hard at work figuring out how to go
> about doing that and we're ready to share the first of our proposals more
> widely. We have developed a plan to remove XBL from Firefox. It's been
> through a successful design review with some of the key engineers and now
> is the time for more comments if you have them. We're planning to start some
> of the work this quarter with it really ramping up next quarter.
>
> Take a look at the plan
> <https://mozilla.github.io/firefox-browser-architecture/text/0007-xbl-design-review-packet.html>
> and let us know what you think. There are a couple of areas where we are
> still investigating concerns:

I very much welcome this plan, especially the fact that Web Components
is part of the replacement. Last time I asked, it sounded like Web
Components was still on the way of being reimplemented and pending some
spec work. In following the webcomponents bug I see there has been
constant progress.

Nevertheless, I'd appreciate if someone could comment on how far along
the Web Components implementation is. Is it now following the agreed
upon version of the spec (I suspect yes), and is the implementation
stable enough that you would consider it ready to ship? What is the next
big milestone for Web Components?

Thunderbird/Lightning uses a lot of XBL components as well that I would
love to get rid of, I am looking forward to making things more
compatible with the future.

Thanks,
Philipp

[Yura Zenevich]

I would also like to bring to the team's attention another force worth
being on the radar (in terms of "forces on the system") - accessibility.
One theme that seems to consistently happen with re-writes such as the ones
from xul to React is regressions in terms of accessibility of newly
re-written components.

thanks,
yura

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[smaug]

On 10/21/2017 11:45 PM, Yura Zenevich wrote:
> I would also like to bring to the team's attention another force worth
> being on the radar (in terms of "forces on the system") - accessibility.
> One theme that seems to consistently happen with re-writes such as the ones
> from xul to React is regressions in terms of accessibility of newly
> re-written components.

Yeah, this is important. I would imagine custom elements in XUL (which might then internally use shadow DOM too) would implement the same
a11y interfaces what XBL implements now.

[smaug]

On 10/21/2017 01:14 PM, Philipp Kewisch wrote:
> On 10/20/17 7:47 PM, Dave Townsend wrote:
>> For some time now we've been talking about moving away from XUL and XBL.
>> The browser architecture team has been hard at work figuring out how to go
>> about doing that and we're ready to share the first of our proposals more
>> widely. We have developed a plan to remove XBL from Firefox. It's been
>> through a successful design review with some of the key engineers and now
>> is the time for more comments if you have them. We're planning to start some
>> of the work this quarter with it really ramping up next quarter.
>>
>> Take a look at the plan
>> <https://mozilla.github.io/firefox-browser-architecture/text/0007-xbl-design-review-packet.html>
>> and let us know what you think. There are a couple of areas where we are
>> still investigating concerns:
>
> I very much welcome this plan, especially the fact that Web Components
> is part of the replacement. Last time I asked, it sounded like Web
> Components was still on the way of being reimplemented and pending some
> spec work. In following the webcomponents bug I see there has been
> constant progress.
>
> Nevertheless, I'd appreciate if someone could comment on how far along
> the Web Components implementation is. Is it now following the agreed
> upon version of the spec (I suspect yes), and is the implementation
> stable enough that you would consider it ready to ship? What is the next
> big milestone for Web Components?

Custom elements implementation is quite close to be ready, and the spec should be
reasonable stable too. There are some bugs and some performance work in the implementation.

Shadow DOM is further behind, especially the implementation, but also the specs tend to
have issues with it, so getting interoperable implementation with other browsers will be a tad
harder. I'm still optimisticly thinking we could have Shadow DOM (for the web) in Nightly by the end of the year -
depends on how much we can focus on it during November.

[Hsin-Yi Tsai]

Regarding Custom elements, there are two remaining bugs ( bug 1378079 and
1406325) under review before we can enable the feature on Nightly in 58.
Once we are ready on Nightly, we will execute performance testing and tune
the performance results (as Olli mentioned some known potential performance
blockers tracked in meta bug 1396567). Then we target at riding the train.

Best regards,
Hsinyi

Shadow DOM is further behind, especially the implementation, but also the
specs tend to
have issues with it, so getting interoperable implementation with other
browsers will be a tad
harder. I'm still optimisticly thinking we could have Shadow DOM (for the
web) in Nightly by the end of the year -
depends on how much we can focus on it during November.






> Thunderbird/Lightning uses a lot of XBL components as well that I would
> love to get rid of, I am looking forward to making things more
> compatible with the future.
>
> Thanks,
> Philipp
>
>
>
>

[Brian Grinstead]

> On Oct 22, 2017, at 3:35 AM, smaug <sm...@welho.com> wrote:
>
> On 10/21/2017 11:45 PM, Yura Zenevich wrote:
>> I would also like to bring to the team's attention another force worth
>> being on the radar (in terms of "forces on the system") - accessibility.
>> One theme that seems to consistently happen with re-writes such as the ones
>> from xul to React is regressions in terms of accessibility of newly
>> re-written components.
>

Thanks, I’ve submitted a PR to the plan to add this point.

> Yeah, this is important. I would imagine custom elements in XUL (which might then internally use shadow DOM too) would implement the same
> a11y interfaces what XBL implements now.

I agree - if we migrate the logic inside of bindings (i.e. formatAccessKey on <label>) and continue to use XUL Elements this should limit the risk of regressions. Two places we should take a closer look at:

1) Ensure that anonymous XBL content is not somehow handled differently from an accessibility standpoint compared to normal DOM children in a Custom Element (or content inside Shadow DOM)
2) We may need to emulate the [role] attribute on a binding definition, which does map to some accessibility code. Do we need to change the way we create the appropriate Accessible class for Custom Elements? It does look at XBLBindingRole as a way to choose which role to assign (i.e. role=”xul:toolbar” on the binding definition). For Custom Elements, it may be easier to use tag names to determine the role, or somehow store it in the custom element registry to avoid setting a ‘role’ attribute on each node during the connectedCallback.
** https://dxr.mozilla.org/mozilla-central/rev/69e24c678a28dc46a4c1bda3ff04b2f6106ff71a/toolkit/content/widgets/button.xml#12
** https://dxr.mozilla.org/mozilla-central/rev/69e24c678a28dc46a4c1bda3ff04b2f6106ff71a/accessible/base/nsAccessibilityService.cpp#1380

[Dave Townsend]

Having not heard any show-stopping concerns with the plan we will start to
proceed with it. In Q4 we intend to:

- Migrate a few bindings and update the plan based on what we learn
- Land XUL support for Custom Elements
- Create tooling to make converting bindings easier
- Begin a bug breakdown for individual bindings

You can follow this work at the meta bug 1397874. Bgrins has made a
public blog post about our plans[1], please reach out to him if you’re
interested in contributing.

[1] https://briangrinstead.com/blog/xbl-in-firefox/

On Fri, Oct 20, 2017 at 10:47 AM Dave Townsend <dtow...@mozilla.com>

wrote:

> For some time now we've been talking about moving away from XUL and XBL.
> The browser architecture team has been hard at work figuring out how to
> go about doing that and we're ready to share the first of our proposals
> more widely. We have developed a plan to remove XBL from Firefox. It's been
> through a successful design review with some of the key engineers and now
> is the time for more comments if you have them. We're planning to start some
> of the work this quarter with it really ramping up next quarter.
>
> Take a look at the plan
> <https://mozilla.github.io/firefox-browser-architecture/text/0007-xbl-design-review-packet.html>
> and let us know what you think. There are a couple of areas where we are
> still investigating concerns:
>

> Performance is of key interest, so we're actively doing experiments to
> validate that Custom Elements can be as performant as XBL
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1387125>.
> The plan relies on being able to use Custom Elements in XUL, so we're
> working on getting a patch
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1404420>for that landed
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1404420>.
> We have a list of <tree> elements in the product and we're evaluating what
> the future is for them.
>

[Bobby Holley]

As one of the lonely few peers for our XBL implementation, I am thrilled
that this is finally happening. My deepest gratitude to everyone involved!

bholley


On Tue, Oct 31, 2017 at 3:06 PM, Dave Townsend <dtow...@mozilla.com>
wrote: