1596530 - Either tighten the restriction on XUL Elements for Custom Element naming or loosen the restriction for (chrome) HTML elements

Status: NEW

(Core :: DOM: Core & HTML, task)

Description

[Brian Grinstead [:bgrins]]

We have special capabilities we allow on XUL elements that were put in place to ease the transition away from XBL. The two main things are:

1. You can use names without a dash. See Bug 1446247, https://groups.google.com/d/msg/firefox-dev/L1ohKKXh1y0/b_i0m_UxEAAJ, and https://searchfox.org/mozilla-central/rev/e7c61f4a68b974d5fecd216dc7407b631a24eb8f/dom/base/nsContentUtils.cpp#2954-2957).
2. You can make a sort of "customized autonomous element" (extending a tag that's already defined as a custom element with [is]). See Bug 1460962, https://groups.google.com/d/msg/firefox-dev/vY2jiR387to/xuo-E3GHBgAJ, and https://searchfox.org/mozilla-central/rev/e7c61f4a68b974d5fecd216dc7407b631a24eb8f/dom/base/CustomElementRegistry.cpp#791-800

Now that we are planning to migrate our XUL Custom Elements to HTML Custom Elements, we are going to run into problems here.

I think our options are:

1. Change things in the platform so that chrome HTML is treated exactly as XUL
2. Change things in the platform so that we can still do "customized autonomous element" in chrome HTML, and rewrite frontend code away from non-dashed tag names
3. Rewrite frontend code away from non-dashed tag names and "customized autonomous elements".

I don't really want to tackle (3) in one go. We rely on the "customized autonomous element" feature in quite a few places, and moving away from it is going to require rewriting CSS and JS consumers in ways that are hard to verify correctness.

I'm open to (2) if that makes things easier. We did originally plan to do this anyway, but it just got put on the backburner in favor of de-XBL work. It's also a large project (though the CSS / JS rewrites would be easier to verify and are more shaped like find/replace).

If (1) is easy then that would unblock things the most quickly.

Comment 1

[Boris Zbarsky [:bzbarsky]]

(1) could be done, but at some performance cost at allthe IsCustomElementName callsites to check for a system principal, right?

And if we want it to work in non-system things (like some of our about: pages), those checks become even more expensive...

Comment 2

[Brian Grinstead [:bgrins]]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #1)

(1) could be done, but at some performance cost at allthe IsCustomElementName callsites to check for a system principal, right?

Yeah, I think we'd need to swap out the aNameSpaceID parameter to that function with a boolean indicating if the caller is a system principal.

And if we want it to work in non-system things (like some of our about: pages), those checks become even more expensive...

I think we'd only need this for system things, since we only load these in documents with isSystemPrincipal: https://searchfox.org/mozilla-central/rev/e7c61f4a68b974d5fecd216dc7407b631a24eb8f/toolkit/components/processsingleton/CustomElementsListener.jsm#16

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

What would be the reasons to do temporary steps (1) or (2), when the end goal should be 3?
(If we are using HTML, better to try to use the HTML as exposed to the web, if possible.)

But if we need to do (1) or (2) first, (2) feels like closer to (3), since it would deal with non-dash'ed-ness.
Implementing (1) or (2) should both be pretty easy, and similar. Principal checks somewhere.

Comment 4

[ExE Boss]

The thing about 2 is that <xul:moz-foo is="moz-bar"/> is currently forbidden: https://searchfox.org/mozilla-central/rev/b58e44b74ef2b4a44bdfb4140c2565ac852504be/dom/base/CustomElementRegistry.cpp#791-800