Open Bug 1216159 Opened 9 years ago Updated 2 years ago

document-element-inserted notification should be more consistent and reliable

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

People

(Reporter: gkrizsanits, Unassigned)

References

Details

We fire it for temporary about:blank pages we load before a content/chrome page is loaded, but if one loads about:blank directly it is not fired. I talked about this with smaug on IRC and his idea is to send this notification either in SetScriptGlobalObject but that would not work for data documents / about:blank or when document element is set, and keep around a flag to make sure it is fired only once. I think this approach could work.
Bill, since WebExtensions are also relying on this notification I thought you might want to take a look at this as well if this matters there or not.
(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #0)
> We fire it for temporary about:blank pages we load before a content/chrome
> page is loaded, but if one loads about:blank directly it is not fired. I
> talked about this with smaug on IRC and his idea is to send this
> notification either in SetScriptGlobalObject but that would not work for
> data documents / about:blank
Yes it would work with about:blank. But it wouldn't work with data documents 
(document.implementation.createHTMLDocument() and such)

But if we want the notification also with data documents, we should use also 
SetScriptHandlingObject. In other words effectively when mScopeObject is set.
Er, perhaps when setting mScopeObject is too early, since it always points to something, but
SetScriptHandlingObject or SetScriptGlobalObject calls should be fine.
...or when SetScopeObject is called.

So, trigger the notification when
SetScriptHandlingObject, SetScriptGlobalObject or SetScopeObject is called and we have a document element. Or if we have mScopeObject and mHasHadScriptHandlingObject is true and we set documentElement.

That would give us consistent behavior, but it would trigger the notification also for data documents, and I don't know if that is ok for addons.
(In reply to Olli Pettay [:smaug] from comment #4)
> ...or when SetScopeObject is called.
> 
> So, trigger the notification when
> SetScriptHandlingObject, SetScriptGlobalObject or SetScopeObject is called
> and we have a document element. Or if we have mScopeObject and
> mHasHadScriptHandlingObject is true and we set documentElement.
> 
> That would give us consistent behavior, but it would trigger the
> notification also for data documents, and I don't know if that is ok for
> addons.

We already do trigger document-element-inserted for data documents and I'm pretty sure we rely on that.

Please also note the DOMDocElementInserted DOM event which should match the observer notification but is very useful for frame scripts to use.
I'm missing to see where document-element-inserted is triggered for data documents, in general.
Documents which go through a parser (HTML or XML) seem to get it, but
do you also get it for document.implementation.createHTMLDocument() for example?
(In reply to Olli Pettay [:smaug] from comment #6)
> I'm missing to see where document-element-inserted is triggered for data
> documents, in general.
> Documents which go through a parser (HTML or XML) seem to get it, but
> do you also get it for document.implementation.createHTMLDocument() for
> example?

With an empty data document it is not triggered, with something in it that hits a parser, it does. As you concluded from the code.
document.implementation.createHTMLDocument() doesn't create an "empty" document. It creates a document
which look like <html><head></head><body></body></html>. It is just that the contents is created without parser.
http://mxr.mozilla.org/mozilla-central/source/dom/base/DOMImplementation.cpp?rev=41dea9df27ed#178
and about blank case
http://mxr.mozilla.org/mozilla-central/source/layout/build/nsContentDLF.cpp?rev=41dea9df27ed#263
(In reply to Olli Pettay [:smaug] from comment #8)
> document.implementation.createHTMLDocument() doesn't create an "empty"
> document.

I have not tested createHTMLDocument() but I would guess it does not trigger. I was talking about the case when the data URI looks like this: data:text/html, and then no parser is used, so no notifications are triggered. But there are a tons of jetpack tests which are relying on this notification for more complex data URIs. And those work. So I guess that's because for the not empty data URIs we use a parser.
(if you load data:text/html, -page, that isn't a "data document". Data document is a document which isn't bound to a browsing context. data: is just a uri scheme.)
(In reply to Olli Pettay [:smaug] from comment #10)
> (if you load data:text/html, -page, that isn't a "data document". Data
> document is a document which isn't bound to a browsing context. data: is
> just a uri scheme.)

I misunderstood then, I don't think we use this right now, I don't know that it would break things to start notifying for them though.
(In reply to Olli Pettay [:smaug] from comment #10)
> (if you load data:text/html, -page, that isn't a "data document". Data
> document is a document which isn't bound to a browsing context. data: is
> just a uri scheme.)

Oh... I think I confused things as well then. I know what a data document is but I thought if I have an iframe with a data URI like this: "data:text/html;charset=utf-8,<script>var documentValue=true;</script>", the result will be a data document using the parent documents global to execute the script. If that is not the case what kind of document will the iframe has? Where will the script be executed and with what principal?
(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #12)
> Oh... I think I confused things as well then. I know what a data document is
> but I thought if I have an iframe with a data URI like this:
> "data:text/html;charset=utf-8,<script>var documentValue=true;</script>", the
> result will be a data document using the parent documents global to execute
> the script. If that is not the case what kind of document will the iframe
> has?
The data "<script>var documentValue=true;</script>" is parsed by HTML parser and it creates 
whatever kind of document is supposed to be created.
(it adds the default <html> and <body> and such if they are missing from the data)

> Where will the script be executed and with what principal?
The iframe gets its own global, and principal is inherited.
... so the following creates two documents and script globals which share the same principal
<html>
  <body>
    <iframe src="data:text/html,"></iframe>
  </body>
</html>
Blocks: abp
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.