Closed Bug 1523655 Opened 7 months ago Closed 7 months ago

Crash in mozilla::dom::Element::AttachAndSetUAShadowRoot

Categories

(Core :: DOM: Core & HTML, defect, P2, critical)

Unspecified
Windows 7
defect

Tracking

()

RESOLVED FIXED
mozilla67
Tracking Status
firefox-esr60 --- unaffected
firefox65 --- unaffected
firefox66 --- unaffected
firefox67 + fixed

People

(Reporter: calixte, Assigned: timdream)

References

(Blocks 1 open bug)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

This bug is for crash report bp-3f06e095-f604-4560-a02c-5469d0190129.

Top 10 frames of crashing thread:

0 xul.dll mozilla::dom::Element::AttachAndSetUAShadowRoot dom/base/Element.cpp:1205
1 xul.dll nsresult nsXMLPrettyPrinter::PrettyPrint dom/xml/nsXMLPrettyPrinter.cpp:83
2 xul.dll nsXMLContentSink::DidBuildModel dom/xml/nsXMLContentSink.cpp:280
3 xul.dll nsParser::ResumeParse parser/htmlparser/nsParser.cpp:1008
4 xul.dll nsParser::OnStopRequest parser/htmlparser/nsParser.cpp:1355
5 xul.dll nsDocumentOpenInfo::OnStopRequest uriloader/base/nsURILoader.cpp:363
6 xul.dll mozilla::net::nsHTTPCompressConv::OnStopRequest netwerk/streamconv/converters/nsHTTPCompressConv.cpp:170
7 xul.dll void mozilla::net::HttpChannelChild::DoOnStopRequest netwerk/protocol/http/HttpChannelChild.cpp:1219
8 xul.dll void mozilla::net::HttpChannelChild::OnStopRequest netwerk/protocol/http/HttpChannelChild.cpp:1102
9 xul.dll mozilla::net::ChannelEventQueue::FlushQueue netwerk/ipc/ChannelEventQueue.cpp:90

There is 1 crash in nightly 67 with buildid 20190129103321. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1510406.

[1] https://hg.mozilla.org/mozilla-central/rev?node=f3ef27bf8c93

Flags: needinfo?(timdream)

Do we know the page that triggers the crash? This is not really actionable...

Flags: needinfo?(timdream)

Unfortunately there is no URL in the report we've.

Emilio, do you think we should just backout bug 1510406 for now or we should let it sit in Nightly for a bit to gather more info?

Flags: needinfo?(emilio)

I'd rather figure this out than backing out, yeah. If this can happen it means that we can stash all the UI in a user-accessible shadow root, which is no good.

Flags: needinfo?(emilio)

Adding ni for Tim as this is likely resulting from bug 1510406 (according to description).

Flags: needinfo?(timdream)
Priority: -- → P2

I've just realized what's wrong from looking at the crash reports!

The crash happens because of this release assertion: MOZ_DIAGNOSTIC_ASSERT(!CanAttachShadowDOM(), "Cannot be used to attach UI shadow DOM");

https://searchfox.org/mozilla-central/rev/78cd247b5d7a08832f87d786541d3e2204842e8e/dom/base/Element.cpp#1205

Looking at it seems fine, until you look at the implentation of the CanAttachShadowDOM():

https://searchfox.org/mozilla-central/rev/78cd247b5d7a08832f87d786541d3e2204842e8e/dom/base/Element.cpp#1092

The check is bogus because it looks for the tag name and skips checking the namespace. So a body tag in the non-HTML namespace will trigger the crash, even though it cannot be used by the web content to attach a shadow root.

data:application/xml,<body><div>hi</div></body>

Simply fix the check will fix this, I think.

Assignee: nobody → timdream
Status: NEW → ASSIGNED
Flags: needinfo?(timdream)
Component: XBL → DOM

A normal shadow root cannot be attached to a non-HTML element so UA Shadow Root should always be allowed.

Tracking for 67 as the number of crashes is already significant on Nightly.

Pushed by timdream@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/22eabcc2038e
Allow non-HTML elements to attach UA Shadow Root r=emilio
Status: ASSIGNED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.