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)

50 Branch
x86_64
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla53
Tracking Status
firefox50 - wontfix
firefox51 - fixed
firefox52 - fixed
firefox53 + fixed

People

(Reporter: srittau, Assigned: edgar)

References

Details

(Keywords: crash, regression, testcase)

Crash Data

Attachments

(4 files)

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
Keywords: crash, testcase
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
Flags: needinfo?(yrliou)
Keywords: regression
Flags: needinfo?(yrliou) → needinfo?(echen)
Please also see bug 1318729, which also involved a crash using Web Components and FF 50. They might be related.
Tracking 53+ for this reproducible crash.
low volume crash with non default settings, not tracking for 52
Edgar, is this bug still in your radar?
Priority: -- → P2
Track 51- and mark 51 fix-optional as the volume of crash is low.
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: nobody → echen
Flags: needinfo?(echen)
Component: Layout → DOM
(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
Attachment #8818179 - Flags: review?(wchen) → review+
Attachment #8818181 - Flags: review?(wchen) → review+
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
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)
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
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)
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?
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 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 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+
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
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?
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 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 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+
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)
(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)
Hah, total fail on my part there!
Flags: needinfo?(ryanvm)
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: