This is so that we can avoid needing mozSystemGroup (to get keypress for
non-printable keys), which in turn prevents racing with the native key event
listeners, see the second patch in bug 1624657.
This turned out to be a bit tricky, because we need to guarantee the ordering of
the search one-offs handling in the searchbar with the usual autocomplete-input
handling. We could try to move this to the popup subclass but this is already a
bigger patch than what I'd like.
We can also revert the customElements.js change I did in bug 1624657, as the bug
is no longer relevant.
Differential Revision: https://phabricator.services.mozilla.com/D69743
This is so that we can avoid needing mozSystemGroup (to get keypress for
non-printable keys), which in turn prevents racing with the native key event
listeners, see the second patch in bug 1624657.
This turned out to be a bit tricky, because we need to guarantee the ordering of
the search one-offs handling in the searchbar with the usual autocomplete-input
handling. We could try to move this to the popup subclass but this is already a
bigger patch than what I'd like.
We can also revert the customElements.js change I did in bug 1624657, as the bug
is no longer relevant.
Differential Revision: https://phabricator.services.mozilla.com/D69743
My patch causes an interesting regression. We stop constructing custom elements
for the stuff inside the edit-bookmark-panel as expected. This means that the
autocomplete-input here:
https://searchfox.org/mozilla-central/rev/3f9e822318e8ec18ce673a9cb983d3608a3e2ed2/browser/components/places/content/editBookmarkPanel.inc.xhtml#81
Doesn't cause autocomplete-input.js to load. That means that it'll load by the
time the searchbar-textbox autocomplete is created, which means that it'll get
upgraded asynchronously. So far so good. However there's an interesting race due
to the way keypress event listeners are setup in autocomplete-input.js. In
particular, it uses the capture phase and the system group:
https://searchfox.org/mozilla-central/rev/3f9e822318e8ec18ce673a9cb983d3608a3e2ed2/toolkit/content/widgets/autocomplete-input.js#38
This means it'll race with the other native / system group event listeners that
get added by the editor component. This caused arrow-up / arrow-down to not work
on the searchbar because the custom element was upgraded async.
This kinda papers over the issue the same way editBookmarkPanel was papering
over it, but ideally we should figure out a way to not use the system group or
keypress there so that we don't race in this awful way. Separate bug, probably.
Differential Revision: https://phabricator.services.mozilla.com/D69730
This uses Shadow DOM slotting instead of XBL, and migrates styles from
using XBL anonymous traversal to using CSS Shadow Parts.
This also removes the basecontrol binding, since this was the last
binding to extend it.
Differential Revision: https://phabricator.services.mozilla.com/D43651
This uses Shadow DOM slotting instead of XBL, and migrates styles from
using XBL anonymous traversal to using CSS Shadow Parts.
This also removes the basecontrol binding, since this was the last
binding to extend it.
Differential Revision: https://phabricator.services.mozilla.com/D43651
As of this change, instances of xul <button> use a custom element.
The button-base xbl binding remains for now, since it is still used
by toolbarbutton, it will be removed soon.
Differential Revision: https://phabricator.services.mozilla.com/D27742
Otherwise we can end up setting the proper attribute on removed children when elements get disconnected
and reconnected.
Differential Revision: https://phabricator.services.mozilla.com/D28306
The existing implementation of inherited attributes keeps a data
structure in a property on the class, but derived classes were
unintentionally getting that structure from their parent class,
preventing derived classes from declaring a different set of inherited
attributes.
Differential Revision: https://phabricator.services.mozilla.com/D28255
This provides a flipped data structure based on the provided inheritedAttributes,
which looks like:
Object<selector, attrs_to_inherit_comma_separated>
To one that looks like:
Object<attr, Array<Array<selector, attr_to_inherit>>
This should improve performance because:
1) We only fetch element at connectedCallback that actually will have attributes inherited.
2) When an attribute changes we can quickly inherit only that one.
Differential Revision: https://phabricator.services.mozilla.com/D27801
This provides a flipped data structure based on the provided inheritedAttributes,
which looks like:
Object<selector, attrs_to_inherit_comma_separated>
To one that looks like:
Object<attr, Array<Array<selector, attr_to_inherit>>
This should improve performance because:
1) We only fetch element at connectedCallback that actually will have attributes inherited.
2) When an attribute changes we can quickly inherit only that one.
Differential Revision: https://phabricator.services.mozilla.com/D27801
For example, you can do MOZ_INSTRUMENT_CUSTOM_ELEMENTS=MozXULElement,Button
to limit output to classes containing those strings in their name
Differential Revision: https://phabricator.services.mozilla.com/D27800
If MOZ_INSTRUMENT_CUSTOM_ELEMENTS is set in the environment, then modify Custom Elements
to wrap each function and property lookup to keep a count and running time. Then print out
tables for each element at startup. Tables can be re-printed with `MozElements.printInstrumentation()`.
Differential Revision: https://phabricator.services.mozilla.com/D24953
For now, only add the MozMenuPopup base class to MozElements,
and don't define a custom element for it with
`customElements.define`. This is to help avoid conflicts in
de-xbl work. (See the bug for details.)
Includes a function to do 'manual slotting', moving child
elements into place. Dynamically adding, modifying, or
removing child nodes after the element is connected needs
to be handled manually as well.
Differential Revision: https://phabricator.services.mozilla.com/D25467
