Closed Bug 1465592 Opened Last year Closed 11 months ago

Enable Shadow DOM unconditionally in chrome documents

Categories

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

task

Tracking

()

RESOLVED FIXED
mozilla64
Tracking Status
firefox64 --- fixed

People

(Reporter: bgrins, Assigned: bgrins)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

I'd like to start testing out usage of Shadow DOM with our Custom Elements in the browser chrome.

Right now `mIsShadowDOMEnabled = nsContentUtils::IsShadowDOMEnabled();` [0] which is keyed off of the "dom.webcomponents.shadowdom.enabled" pref.

For Custom Elements we updated the CustomElementRegistry::IsCustomElementEnabled check to include a principle check [1] and make it always on. I think we could do the same here.

[0]: https://searchfox.org/mozilla-central/rev/5a744713370ec47969595e369fd5125f123e6d24/dom/base/nsDocument.cpp#2124 [1]: [1]: https://searchfox.org/mozilla-central/rev/5a744713370ec47969595e369fd5125f123e6d24/dom/base/CustomElementRegistry.cpp#293
I'm not quite sure whether Shadow DOM is ready enough for being enabled always in browser chrome.
(In reply to Olli Pettay [:smaug] from comment #2)
> I'm not quite sure whether Shadow DOM is ready enough for being enabled
> always in browser chrome.

OK, good to know - this isn't urgent. Are there any particular bugs we should block this on?
Mostly just generic stability. Custom Elements had been enabled in Nightly for months before it was enabled always for chrome.

From https://bugzilla.mozilla.org/showdependencytree.cgi?id=1205323&hide_resolved=1
focus handling stuff probably needs still some small tweaks and directionality stuff is unclear.
I assume without proper directionality support, FF UI would be broken on rtl locales.
Directionality depends on spec issues to be sorted out.
Alright, we'll put this bug on hold until we get the green light to start using it.
Priority: -- → P3
Well, Web Components (Shadow DOM and Custom Elements) will be shipping in Firefox 63 stable, so this can probably be done now.
See Also: → 1471947
(In reply to ExE Boss from comment #6)
> Well, Web Components (Shadow DOM and Custom Elements) will be shipping in
> Firefox 63 stable, so this can probably be done now.

I'm not sure that the directionality stuff listed in Comment 4 has been resolved, though. Olli - is there a particular spec issue / bug to follow for that?
Flags: needinfo?(bugs)
Directionality stuff isn't fixed in the spec level, but we have implementation which tries to mimic other browsers in common cases. But it is expected that all the browsers will need to change their behavior, since what the implementations do atm isn't what people seem to want.

https://github.com/whatwg/html/issues/3699
Flags: needinfo?(bugs)
Comment on attachment 8982293 [details]
Bug 1465592 - Enable Shadow DOM unconditionally in chrome documents

Moved this to phab and added a test. :smaug, I'll leave it up to you as far as when you are comfortable with us using this so feel free to clear the review for now if you aren't.
Attachment #8982293 - Attachment is obsolete: true
Comment on attachment 9010316 [details]
Bug 1465592 - Enable Shadow DOM unconditionally in chrome documents;r=smaug

Olli Pettay [:smaug] (r- if the bug doesn't explain what the change(s) are about.) has approved the revision.
Attachment #9010316 - Flags: review+
Assignee: nobody → bgrinstead
Status: NEW → ASSIGNED
Pushed by bgrinstead@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/80ccc40bdd0a
Enable Shadow DOM unconditionally in chrome documents;r=smaug
https://hg.mozilla.org/mozilla-central/rev/80ccc40bdd0a
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Will this be uplifted to Firefox 63?
Flags: needinfo?(bgrinstead)
(In reply to ExE Boss from comment #14)
> Will this be uplifted to Firefox 63?

No. We aren't shipping any Shadow DOM in the chrome in 63.
Flags: needinfo?(bgrinstead)
Component: DOM → DOM: Core & HTML
Type: enhancement → task
You need to log in before you can comment on or make changes to this bug.