Closed
Bug 1319255
Opened 4 years ago
Closed 4 years ago
Not exposing HTMLContentElement on Window breaks chrome experiments main page
Categories
(Core :: DOM: Core & HTML, defect, P2)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla53
People
(Reporter: bzbarsky, Assigned: bzbarsky)
References
()
Details
Attachments
(3 files)
5.64 KB,
patch
|
wchen
:
review+
jcristau
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
9.51 KB,
patch
|
wchen
:
review+
jcristau
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
7.01 KB,
patch
|
wchen
:
review+
jcristau
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
[Tracking Requested - why for this release]: [Tracking Requested - why for this release]: See bug 1316347 comment 6 and following. I just verified that the HTMLContentElement change is what causes the problem. This confuses me quite a bit, because HTMLContentElement doesn't actually _do_ anything that I know of, when it's exposed. Also, it's not exposed in Safari but the site works fine there...
![]() |
Assignee | |
Comment 1•4 years ago
|
||
Ah, I bet I know what the problem is. Even when webcomponents are disabled, document.createElement("content") still hands back an element with HTMLContentElement.prototype as its proto. I expect this is confusing Polymer, because now our internal (non-functional as far as they're concerned) getDistributedNodes() gets called instead of their polyfill. Or something along those lines. William, is it expected that even when webcomponents are disabled <content> elements end up with webcomponents stuff on their proto chain?
![]() |
Assignee | |
Comment 3•4 years ago
|
||
Attachment #8813397 -
Flags: review?(wchen)
![]() |
Assignee | |
Updated•4 years ago
|
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
![]() |
Assignee | |
Comment 4•4 years ago
|
||
Attachment #8813398 -
Flags: review?(wchen)
![]() |
Assignee | |
Comment 5•4 years ago
|
||
Attachment #8813400 -
Flags: review?(wchen)
Comment 7•4 years ago
|
||
Comment on attachment 8813400 [details] [diff] [review] This fixes the chrome experiments site for me Thanks for writing the patches.
Flags: needinfo?(wchen)
Attachment #8813400 -
Flags: review?(wchen) → review+
Updated•4 years ago
|
Attachment #8813397 -
Flags: review?(wchen) → review+
Updated•4 years ago
|
Attachment #8813398 -
Flags: review?(wchen) → review+
Pushed by bzbarsky@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/1bacb2975324 part 1. Stop doing casts to HTMLShadowElement* simply based on tag. r=wchen https://hg.mozilla.org/integration/mozilla-inbound/rev/93d4161c74bf part 2. Stop doing casts to HTMLContentElement* simply based on tag. r=wchen https://hg.mozilla.org/integration/mozilla-inbound/rev/03acde1081c3 part 3. Don't create special elements for <shadow> and <content> unless webcomponents are enabled. r=wchen
![]() |
Assignee | |
Comment 9•4 years ago
|
||
Comment on attachment 8813397 [details] [diff] [review] part 1. Stop doing casts to HTMLShadowElement* simply based on tag Approval Request Comment [Feature/regressing bug #]: Bug 1316347 [User impact if declined]: Chrome experiments site broken. Possibly also other Polymer-using things. [Describe test coverage new/current, TreeHerder]: Test coverage around this stuff is a bit sparse. [Risks and why]: There are various changes to our content iterator code that might be a bit risky. It might be safer to back out bug 1316347 on 52 instead. On the other hand, continuing to ship those properties on Window in ESR 52 is a bit unfortunate. [String/UUID change made/needed]: None
Attachment #8813397 -
Flags: approval-mozilla-aurora?
![]() |
Assignee | |
Updated•4 years ago
|
Attachment #8813398 -
Flags: approval-mozilla-aurora?
![]() |
Assignee | |
Updated•4 years ago
|
Attachment #8813400 -
Flags: approval-mozilla-aurora?
Comment 10•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/1bacb2975324 https://hg.mozilla.org/mozilla-central/rev/93d4161c74bf https://hg.mozilla.org/mozilla-central/rev/03acde1081c3
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Comment 11•4 years ago
|
||
Tracking for 52. Still pondering whether a backout or uplift is the way to go here, leaning towards backout for now...
status-firefox52:
--- → affected
Comment 13•4 years ago
|
||
Comment on attachment 8813397 [details] [diff] [review] part 1. Stop doing casts to HTMLShadowElement* simply based on tag fix regression in aurora52 I changed my mind a bit, since this is a long-ish aurora cycle I'm hoping we will have time to discover any fallout from this before 52 goes to beta.
Attachment #8813397 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 14•4 years ago
|
||
Comment on attachment 8813398 [details] [diff] [review] part 2. Stop doing casts to HTMLContentElement* simply based on tag fix regression in aurora52
Attachment #8813398 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 15•4 years ago
|
||
Comment on attachment 8813400 [details] [diff] [review] This fixes the chrome experiments site for me fix regression in aurora52
Attachment #8813400 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 16•4 years ago
|
||
bugherderuplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/c86c1be91253 https://hg.mozilla.org/releases/mozilla-aurora/rev/e053c5265eb2 https://hg.mozilla.org/releases/mozilla-aurora/rev/a07b4a7ba48b
Updated•2 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•