Closed
Bug 1318630
Opened 8 years ago
Closed 8 years ago
Crash in nsCSSFrameConstructor::FindInputData with two-argument form of document.createElement() (dom.webcomponents.enabled=true)
Categories
(Core :: DOM: Core & HTML, defect, P2)
Tracking
()
People
(Reporter: srittau, Assigned: edgar)
References
Details
(Keywords: crash, regression, testcase)
Crash Data
Attachments
(4 files)
3.63 KB,
patch
|
wchen
:
review+
jcristau
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
3.67 KB,
patch
|
wchen
:
review+
jcristau
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
3.66 KB,
patch
|
lizzard
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
3.67 KB,
patch
|
lizzard
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
Using Firefox 50.0 with dom.webcomponents.enabled set to true, the following JavaScript code will hard-crash the browser:
class MyElement extends HTMLInputElement {}
document.registerElement("my-element", {
prototype: MyElement.prototype,
extends: "input"
});
const element = document.createElement("input", {is: "my-element"});
document.body.appendChild(element);
If you replace the last line by:
element.type = "number";
you get the error message "TypeError: 'set type' called on an object that does not implement interface HTMLInputElement."
Using innerHTML will work fine:
const container = document.createElement("div");
container.innerHTML = '<input is="my-element"/>';
const element = container.firstChild;
element.type = "number";
document.body.appendChild(element);
This problem is reproducible in Firefox 50.0, on Debian Linux (package 50.0-1) and on Windows 7 using the official Firefox download. Yesterday, it was also reproducible using a Firefox 51 Beta version on Windows.
Indeed, this JS code crashes Firefox (50/53) in non-e10s mode, but not in e10s which throws exception.
https://crash-stats.mozilla.com/report/index/f8f801f2-1e0f-4e2b-8df6-a04812161118
Severity: normal → critical
Status: UNCONFIRMED → NEW
Crash Signature: [@ nsCSSFrameConstructor::FindInputData ]
Component: General → Layout
Ever confirmed: true
Product: Firefox → Core
Summary: hard crash with two-argument form of document.createElement() → [non-e10s] Crash in nsCSSFrameConstructor::FindInputData with two-argument form of document.createElement() (dom.webcomponents.enabled=true)
Reg range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=db0243f476257
6ce4874d56bd3c92c56fcf78ab7&tochange=fc1d44b2cb7b7d7c47a365bddfc23ff991505003
Jocelyn, can you check this regression crash after your patches in bug 1276579.
You need to disable e10s to reproduce the crash in Nightly.
Blocks: 1276579
status-firefox50:
--- → affected
status-firefox51:
--- → affected
status-firefox52:
--- → affected
status-firefox53:
--- → affected
tracking-firefox50:
--- → ?
tracking-firefox51:
--- → ?
tracking-firefox52:
--- → ?
tracking-firefox53:
--- → ?
Flags: needinfo?(yrliou)
Keywords: regression
Assignee | ||
Updated•8 years ago
|
Flags: needinfo?(yrliou) → needinfo?(echen)
Reporter | ||
Comment 3•8 years ago
|
||
Please also see bug 1318729, which also involved a crash using Web Components and FF 50. They might be related.
Comment 5•8 years ago
|
||
low volume crash with non default settings, not tracking for 52
Comment 7•8 years ago
|
||
Track 51- and mark 51 fix-optional as the volume of crash is low.
Assignee | ||
Comment 8•8 years ago
|
||
The crash could not be reproduced with dom.webcomponents.customelements.enabled set to true. I suspect there is something wrong on handling feature control property.
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → echen
Flags: needinfo?(echen)
Assignee | ||
Updated•8 years ago
|
Component: Layout → DOM
very low volume crash, wontfix for 50.1.0 release
Assignee | ||
Comment 10•8 years ago
|
||
(In reply to Edgar Chen [:edgar][:echen] from comment #8)
> The crash could not be reproduced with
> dom.webcomponents.customelements.enabled set to true. I suspect there is
> something wrong on handling feature control property.
Beside the feature control property, we always create HTMLElement for custom element [1], so we got "TypeError: 'set type' called on an object that does not implement interface HTMLInputElement." when access the attribute of input element.
[1] http://searchfox.org/mozilla-central/rev/5ee2bd8800b007d6c120d9521d5bf01131885afb/dom/html/nsHTMLContentSink.cpp#256-268
Assignee | ||
Comment 11•8 years ago
|
||
Assignee | ||
Comment 12•8 years ago
|
||
Assignee | ||
Comment 13•8 years ago
|
||
Assignee | ||
Updated•8 years ago
|
Attachment #8818179 -
Flags: review?(wchen)
Assignee | ||
Updated•8 years ago
|
Attachment #8818181 -
Flags: review?(wchen)
Updated•8 years ago
|
Attachment #8818179 -
Flags: review?(wchen) → review+
Updated•8 years ago
|
Attachment #8818181 -
Flags: review?(wchen) → review+
Comment 14•8 years ago
|
||
Pushed by echen@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7ce261714f79
Part 1: Fix missing control pref checks for custom element feature; r=wchen
https://hg.mozilla.org/integration/mozilla-inbound/rev/38bc75a0a89e
Part 2: Create correct html element object when "is" is specified for custom element; r=wchen
Assignee | ||
Comment 15•8 years ago
|
||
This also happens on e10s, so I modified the bug description to reflect the fact more.
Summary: [non-e10s] Crash in nsCSSFrameConstructor::FindInputData with two-argument form of document.createElement() (dom.webcomponents.enabled=true) → Crash in nsCSSFrameConstructor::FindInputData with two-argument form of document.createElement() (dom.webcomponents.enabled=true)
Comment 16•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/7ce261714f79
https://hg.mozilla.org/mozilla-central/rev/38bc75a0a89e
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Comment 17•8 years ago
|
||
Please request Aurora/Beta approval on this when you get a chance (assuming you feel the risk is sufficiently low for doing so).
Flags: needinfo?(echen)
Assignee | ||
Comment 18•8 years ago
|
||
Comment on attachment 8818179 [details] [diff] [review]
Part 1: Fix missing control pref checks for custom element feature, v1
Approval Request Comment
[Feature/Bug causing the regression]: Bug 1276579.
[User impact if declined]: Browser/Tab crash when enabling and using custom element feature.
[Is this code covered by automated tests?]: Yes.
[Has the fix been verified in Nightly?]: Yes.
[Needs manual test from QE? If yes, steps to reproduce]: No.
[List of other uplifts needed for the feature/fix]: None.
[Is the change risky?]: No.
[Why is the change risky/not risky?]: custom element feature is preffed off by default on aurora.
[String changes made/needed]: None.
Flags: needinfo?(echen)
Attachment #8818179 -
Flags: approval-mozilla-aurora?
Assignee | ||
Comment 19•8 years ago
|
||
Comment on attachment 8818181 [details] [diff] [review]
Part 2: Create correct html element object when "is" is specified for custom element, v1
Approval Request Comment
[Feature/Bug causing the regression]: Bug 1276579.
[User impact if declined]: Browser/Tab crash when enabling and using custom element feature.
[Is this code covered by automated tests?]: Yes.
[Has the fix been verified in Nightly?]: Yes.
[Needs manual test from QE? If yes, steps to reproduce]: No.
[List of other uplifts needed for the feature/fix]: None.
[Is the change risky?]: No.
[Why is the change risky/not risky?]: custom element feature is preffed off by default on aurora.
[String changes made/needed]: None.
Attachment #8818181 -
Flags: approval-mozilla-aurora?
Comment 20•8 years ago
|
||
Comment on attachment 8818179 [details] [diff] [review]
Part 1: Fix missing control pref checks for custom element feature, v1
fix crash with custom element feature on aurora52
Attachment #8818179 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 21•8 years ago
|
||
Comment on attachment 8818181 [details] [diff] [review]
Part 2: Create correct html element object when "is" is specified for custom element, v1
fix crash with custom element feature on aurora52
Attachment #8818181 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Updated•8 years ago
|
Comment 22•8 years ago
|
||
bugherder uplift |
Assignee | ||
Comment 23•8 years ago
|
||
Part 1 patch for beta.
Assignee | ||
Comment 24•8 years ago
|
||
Part 2 patch for beta
Assignee | ||
Updated•8 years ago
|
Attachment #8823491 -
Attachment description: [beta] Part 1: Fix missing control pref checks for custom element feature, v1 → [beta] Part 1: Fix missing control pref checks for custom element feature, v1, r=wchen
Assignee | ||
Comment 25•8 years ago
|
||
Comment on attachment 8823491 [details] [diff] [review]
[beta] Part 1: Fix missing control pref checks for custom element feature, v1, r=wchen
Approval Request Comment
[Feature/Bug causing the regression]: Bug 1276579.
[User impact if declined]: Browser/Tab crash when enabling and using custom element feature.
[Is this code covered by automated tests?]: Yes.
[Has the fix been verified in Nightly?]: Yes.
[Needs manual test from QE? If yes, steps to reproduce]: No.
[List of other uplifts needed for the feature/fix]: None.
[Is the change risky?]: No.
[Why is the change risky/not risky?]: custom element feature is preffed off by default on beta.
[String changes made/needed]: None.
Attachment #8823491 -
Flags: approval-mozilla-beta?
Assignee | ||
Comment 26•8 years ago
|
||
Comment on attachment 8823493 [details] [diff] [review]
[beta] Part 2: Create correct html element object when "is" is specified for custom element, v1, r=wchen
Approval Request Comment
[Feature/Bug causing the regression]: Bug 1276579.
[User impact if declined]: Browser/Tab crash when enabling and using custom element feature.
[Is this code covered by automated tests?]: Yes.
[Has the fix been verified in Nightly?]: Yes.
[Needs manual test from QE? If yes, steps to reproduce]: No.
[List of other uplifts needed for the feature/fix]: None.
[Is the change risky?]: No.
[Why is the change risky/not risky?]: custom element feature is preffed off by default on beta.
[String changes made/needed]: None.
Attachment #8823493 -
Flags: approval-mozilla-beta?
Comment 27•8 years ago
|
||
Comment on attachment 8823491 [details] [diff] [review]
[beta] Part 1: Fix missing control pref checks for custom element feature, v1, r=wchen
This isn't a high volume crash on release (5 crashes in a month)
But given that it only would happen with non default prefs, why not try it if the behavior is more correct.
Attachment #8823491 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 28•8 years ago
|
||
Comment on attachment 8823493 [details] [diff] [review]
[beta] Part 2: Create correct html element object when "is" is specified for custom element, v1, r=wchen
This should land for 51 beta 13 next week.
Attachment #8823493 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 29•8 years ago
|
||
This is hitting conflicts due to bug 1309140. Not sure if you want to just rebase around it for the Beta uplift or get that renaming uplifted too.
Flags: needinfo?(echen)
Assignee | ||
Comment 30•8 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #29)
> This is hitting conflicts due to bug 1309140. Not sure if you want to just
> rebase around it for the Beta uplift or get that renaming uplifted too.
Attachment 8823491 [details] [diff] and Attachment 8823493 [details] [diff] are the patches rebased for the Beta uplift. Please let me know if they still hit the conflicts, thank you.
Flags: needinfo?(echen) → needinfo?(ryanvm)
Comment 32•8 years ago
|
||
bugherder uplift |
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•