зеркало из https://github.com/mozilla/gecko-dev.git
Bug 1624657 - Eagerly load autocomplete-input custom element. r=Gijs
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 --HG-- extra : moz-landing-system : lando
This commit is contained in:
Родитель
6a2699f75b
Коммит
efbf711e30
|
@ -793,6 +793,17 @@
|
|||
"chrome://global/content/elements/toolbarbutton.js",
|
||||
"chrome://global/content/elements/tree.js",
|
||||
"chrome://global/content/elements/wizard.js",
|
||||
// We load autocomplete-input eagerly, because we use system event
|
||||
// listeners to be able to see keypress events for non-printable keys
|
||||
// (see bug 1434837), and in the capture phase, for some reason.
|
||||
//
|
||||
// That means that they can run after the actual internal <input> element
|
||||
// event listeners if custom element construction is not synchronous, and
|
||||
// thus be default-prevented by them.
|
||||
//
|
||||
// This all seems pretty fishy, ideally we'd stop using keypress for
|
||||
// these events, but for now this preserves behavior.
|
||||
"chrome://global/content/elements/autocomplete-input.js",
|
||||
]) {
|
||||
Services.scriptloader.loadSubScript(script, window);
|
||||
}
|
||||
|
@ -801,10 +812,6 @@
|
|||
["findbar", "chrome://global/content/elements/findbar.js"],
|
||||
["menulist", "chrome://global/content/elements/menulist.js"],
|
||||
["search-textbox", "chrome://global/content/elements/search-textbox.js"],
|
||||
[
|
||||
"autocomplete-input",
|
||||
"chrome://global/content/elements/autocomplete-input.js",
|
||||
],
|
||||
["stringbundle", "chrome://global/content/elements/stringbundle.js"],
|
||||
[
|
||||
"printpreview-toolbar",
|
||||
|
|
Загрузка…
Ссылка в новой задаче