9438832551
As it won't after that if something flushes (because FlushPendingNotifications will just ignore the flush if the sink is no longer a document observer). Otherwise we might not notify of some document insertions, and that might reasonably confuse layout if it has started before. The reason we don't have more similar crashes seems to be two different things: * That in the crashtest, the custom element triggers a partial parser flush via the innerHTML setter while the parser is creating the element. That causes the parser to flush the previous text node (which tells layout to go look under the <body> for children) but unless we FlushTags() once we're done we won't know about the custom-element child. * That there's no end tag for the <body> or <html> nodes, so we don't reach this code when we end them: https://searchfox.org/mozilla-central/rev/df23c6e58c6be1eb8399e475878f73d4867bef87/dom/xml/nsXMLContentSink.cpp#1041-1047 Differential Revision: https://phabricator.services.mozilla.com/D106421
17 lines
397 B
HTML
17 lines
397 B
HTML
<?xml version="1.0" encoding="utf-8"?>
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<script>
|
|
customElements.define('custom-el-1',
|
|
class extends HTMLElement {
|
|
constructor () {
|
|
super()
|
|
this.attachShadow({ mode: 'open' })
|
|
this.shadowRoot.innerHTML = '<span/>'
|
|
}
|
|
})
|
|
</script>
|
|
</head>
|
|
<body>
|
|
<custom-el-1/>
|