2064276 - Parse the urlbar input's markup without MozXULElement

Status: RESOLVED FIXED

(Firefox :: Address Bar, task)

Description

[Dão Gottwald [:dao]]

UrlbarInputBase.fragment builds the input's DOM with window.MozXULElement.parseXULToFragment(), which a content realm doesn't have, so <moz-urlbar> can't construct itself on about:newtab.

parseXULToFragment is a DOMParser parse of the markup wrapped in a XUL <box> declaring the XUL and XHTML namespaces, followed by stripping whitespace-only text nodes. Two pieces of it are chrome-only: forceEnableXULXBL() and parseFromSafeString(). The first is load-bearing -- a content DOMParser cannot create XUL elements at all -- so a content realm has to map the markup's XUL default namespace to HTML rather than reproduce the parse as-is.

That works because the markup is almost entirely html:-prefixed: 35 tags across 9 element types, against a single XUL moz-input-box, which then parses as an undefined custom element. Whether the input needs a substitute for it in a content document is still open.

Comment 1

[Dão Gottwald [:dao]]

Attachment: Bug 2064276 - Parse the input's markup with DOMParser. r?mbeier!

parseXULToFragment is chrome-only, and one of the reasons is load-bearing: a
content document can hold no XUL elements at all, which is what
forceEnableXULXBL grants. So the content branch maps the markup's XUL default
namespace to HTML, and its lone XUL element, moz-input-box, parses as an
undefined custom element. Whether the input needs a substitute there is the next
thing to find out.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/fcee5de428a0
https://hg.mozilla.org/integration/autoland/rev/37e5d2ab84cf
Parse the input's markup with DOMParser. r=mbeier,urlbar-reviewers

Comment 3

[Dão Gottwald [:dao]]

Attachment: Bug 2064276 - Drop the markup's whitespace text nodes. r?mbeier!

DOMParser keeps the whitespace between the markup's elements, and those text nodes change the accessibility tree the input exposes: the search bar gains an empty section child, which browser_searchbar_new.js catches. Only a build slow enough to assert the tree before it settles sees it, so opt is green while asan, tsan and debug fail; MOZ_CHAOSMODE with --repeat reproduces it on an opt build.

Comment 4

[Serban Stanca [:SerbanS]]

Reverted this because it was causing mochitests failures in browser_searchbar_new.js.

• Revert link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | accessible/tests/browser/tree/browser_searchbar_new.js | test_searchbar_a11y_tree - [DOM node id: searchbar-new, role: grouping, address: [xpconnect wrapped nsIAccessible]] has an extra child at index 1 : [role: section, address: [xpconnect wrapped nsIAccessible]]

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/6f9220dcc14b
https://hg.mozilla.org/integration/autoland/rev/6f131671631b
Parse the input's markup with DOMParser. r=mbeier,urlbar-reviewers
https://github.com/mozilla-firefox/firefox/commit/e3871704dde7
https://hg.mozilla.org/integration/autoland/rev/7a54558aa3b3
Drop the markup's whitespace text nodes. r=mbeier

Comment 6

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/37e5d2ab84cf

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/5053db6c195d
https://hg.mozilla.org/integration/autoland/rev/fe7ccfaec3cb
Parse the input's markup with DOMParser. r=mbeier,urlbar-reviewers
https://github.com/mozilla-firefox/firefox/commit/931086a872ff
https://hg.mozilla.org/integration/autoland/rev/daea5ef944fd
Drop the markup's whitespace text nodes. r=mbeier

Comment 8

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/6f131671631b
https://hg.mozilla.org/mozilla-central/rev/7a54558aa3b3
https://hg.mozilla.org/mozilla-central/rev/fe7ccfaec3cb
https://hg.mozilla.org/mozilla-central/rev/daea5ef944fd