XUL/XBL Replacement Newsletter #8

Mon Oct 8 22:15:33 UTC 2018

To close the loop here — the in-tree document is now published at

https://firefox-source-docs.mozilla.org/toolkit/content/toolkit_widgets/ua_widget.html

On Mon, Sep 24, 2018 at 2:38 PM Robert Helmer <rhelmer at mozilla.com> wrote:

> You can write your comments in JSDoc style and API docs will
> automatically be published to http://firefox-source-docs.mozilla.org/
> provided your part of the tree opts-in to it:
>
> https://groups.google.com/forum/#!topic/firefox-dev/p2mOCab9Ufg
> On Mon, Sep 24, 2018 at 1:08 PM Tim Guan-tin Chien <timdream at mozilla.com>
> wrote:
> >
> > Hi Felipe,
> >
> > Thanks for the suggestion on documenting the APIs. I am not sure where
> will be the best place to put it, but for the sake of making sure it is
> updated, I am leaning toward adding it as a big comment in
> UAWidgetsChild.jsm, where all the widgets are being initialized.
> >
> > Let me know what you think. Thanks.
> >
> >
> > Tim
> >
> > On Mon, Sep 24, 2018 at 12:56 PM Felipe G <felipc at gmail.com> wrote:
> >>
> >> This is an impressive amount of work! Great to hear about all this
> progress!
> >>
> >> I'm interested in learning more about the UA Widgets API.. Will there
> be a write up or some documentation about how the final API works? I saw
> the bug but it's too daunting to get all the information from there.
> >>
> >> Felipe
> >>
> >> On Mon, Sep 24, 2018 at 12:37 PM Brian Grinstead <
> bgrinstead at mozilla.com> wrote:
> >>>
> >>> This is the eighth edition of the XBL Replacement Newsletter. Since
> the last update there’ve been steps towards removing in-content XBL,
> flexbox performance improvements, and new chrome Custom Element
> capabilities.
> >>>
> >>> In Content XBL → UA Widgets
> >>>
> >>> We have been using XBL inside web content for a long time for
> rendering UI like scrollbars. But there are even more complex situations
> where we use XBL to insert DOM and run JS inside the content document. For
> example, with <video controls> or <input type="date">.
> >>>
> >>> Tim Guan-tin Chien has been busy working on an alternative to this
> setup. Now that bug 1484048 has landed, the video controls are working
> entirely without XBL in nightly builds. Instead, we are using Shadow DOM
> and JS running inside of a sandbox. The setup is coined “UA Widgets” - you
> can read more about the design in bug 1431255.
> >>>
> >>> This setup is pretty complex, mostly because of the level of
> encapsulation needed. The web content must not be able to probe into the
> DOM inserted, nor interact with the JS directly. The sandboxes are created
> per-origin as an extra layer of security to ensure isolation among
> different origins in the same content process.
> >>>
> >>> Now that the first binding is done and the framework is in place, Tim
> is setting his sights on the rest. There aren’t too many in-content
> bindings left after this. The most complex ones are the date and time
> pickers, the marquee tag, and the “click to play” plugin UI. Once we remove
> the last one that’ll let us remove the in-content XBL implementation which
> we expect will provide performance, security, and code simplification
> benefits.
> >>>
> >>> Flexbox performance improvements
> >>>
> >>> One of the main aspects of the UI that we’d like to migrate away from
> XUL and towards web standards is flexbox. One reason this is important is
> that it’ll make it easier to use HTML elements in the browser chrome. But
> the main thing I wanted to talk about here is that it creates a need to
> greatly improve the performance of CSS flexbox.
> >>>
> >>> Flexbox perf issues affect web content in Firefox - for example
> Twitter DMs, WhatsApp, and number of other sites. And as Neil noticed in
> 2015, switching the browser chrome to use CSS flexbox causes large perf
> regressions. To track this, we added a pref to enable CSS flexbox in the
> browser chrome which lets us measure the difference between XUL and CSS
> flexbox with Talos.
> >>>
> >>> In order to improve performance in both these environments (web
> content, and chrome with CSS flex layout), the layout team has prioritized
> optimizing flexbox during the second half of this year. Daniel Holbert
> landed the first major piece of this effort recently in Bug 1490890. This
> had a massive impact on some DevTools panels that are already using CSS
> flex, especially the webconsole. As Nicolas Chevobbe noted, one console
> test case where characters get typed into the input field sped up from
> ~800ms to ~100ms.
> >>>
> >>> It’s still TBD when it’ll get fast enough to lay out the browser
> chrome, but each step in that direction will make websites using flexbox
> faster in Firefox. Keep an eye on the main flexbox performance metabug if
> you want to follow along.
> >>>
> >>> XPCOM support for (chrome) Custom Elements
> >>>
> >>> XBL has a way to wire up XPCOM interfaces with DOM elements. You may
> have seen this before inside of XBL bindings - for example the browser
> binding uses implements="nsIObserver, nsIBrowser". This lets the XBL
> binding provide the implementation for functions on that interface, and
> lets other code QueryInterface to that interface using the element.
> >>>
> >>> This feature is (obviously) not part of the specification for Custom
> Elements. But if you look closely at our tree of XBL bindings, you can see
> that a bunch of them inherit from basecontrol which relies on this feature.
> That means we’ve been blocked off from migrating most of those bindings to
> Custom Elements.
> >>>
> >>> We are unblocking this on two fronts:
> >>>
> >>> Adding XPCOM support to chrome Custom Elements. This is done - Neil
> Deakin landed this feature in bugs 1461742 and 1478372.
> >>> Remove individual interfaces when possible. Alex Surkov recently
> removed nsIDOMXULLabelElement, nsIDOMXULLabeledControlElement, and
> nsIDOMXULCheckboxElement, for example. This also has some overlap with the
> work bz did to remove nsIDOMElement and nsIDOMNode a few months back, and
> we’re hoping to do more of this when it makes sense.
> >>>
> >>> Binding Removals
> >>>
> >>> There are 153 bindings left, compared to 161 from the last update and
> 300 from the start of the project. Here’s a list of changes:
> >>>
> >>> I migrated <findbar> to a Custom Element, which let us remove the
> findbar and findbar-textbox bindings. This was one of the earlier Custom
> Element migration bugs on file so it’s a good opportunity to look back on
> the work that’s been done to unblock it - see the dependency tree to get a
> sense for that.
> >>> I also migrated tabbox to a Custom Element, and then Dão Gottwald
> removed some unused code paths that we discovered during the review.
> >>> Paolo Amadini removed the unused menu-button and menu-button-base
> bindings.
> >>> Paolo also removed the menulist-editable binding.
> >>> Tim added the UA Widget capability discussed above, which let us
> remove videoControls, noControls, and prettyprint bindings. Notably, this
> caused the second biggest one day drop in lines of XBL code in m-c that
> we’ve had so far.
> >>>
> >>>
> >>> _______________________________________________
> >>> firefox-dev mailing list
> >>> firefox-dev at mozilla.org
> >>> https://mail.mozilla.org/listinfo/firefox-dev
> >>
> >> _______________________________________________
> >> firefox-dev mailing list
> >> firefox-dev at mozilla.org
> >> https://mail.mozilla.org/listinfo/firefox-dev
> >
> > _______________________________________________
> > firefox-dev mailing list
> > firefox-dev at mozilla.org
> > https://mail.mozilla.org/listinfo/firefox-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20181008/cea187e2/attachment-0001.html>