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

toolkit/content/customElements.js

@@ -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",