Is null document.location expected in this case or a bug?

[a***@yahoo.com]

In appcontent.DOMContentLoaded for an iframe, which in an inline script
changes parent.location and then assigns its own location to about:blank,
document.location is null, window.location is about:blank and document.URL
is the actual url.

Even though location has been changed before DOMContentLoaded, the
navigation presumably has not started, so should location be something other
than the actual url of the document?

Why are document.location and window.location out of sync?

Why is document.location null?

[Boris Zbarsky]

Post by a***@yahoo.com
In appcontent.DOMContentLoaded for an iframe, which in an inline script
changes parent.location and then assigns its own location to about:blank,
document.location is null, window.location is about:blank and document.URL
is the actual url.
Even though location has been changed before DOMContentLoaded, the
navigation presumably has not started

If document.location is null, then not only has navigation started but
the new document is already partway through being loaded and the old
document is not the current document in the window, I would think...

You can tell this also from the fact that window.location is about:blank.

Post by a***@yahoo.com
Why are document.location and window.location out of sync?

Are document and window.document equal?

-Boris

[a***@yahoo.com]

Post by a***@yahoo.com
In appcontent.DOMContentLoaded for an iframe, which in an inline script
changes parent.location and then assigns its own location to about:blank,
document.location is null, window.location is about:blank and
document.URL
is the actual url.
Even though location has been changed before DOMContentLoaded, the
navigation presumably has not started

If document.location is null, then not only has navigation started but the
new document is already partway through being loaded and the old document
is not the current document in the window, I would think...
You can tell this also from the fact that window.location is about:blank.

event.target is still the old document. If the old document is (partially
or completely) gone, does it make sense to fire a DOMContentLoaded, whose
meaning is that the dom of the target (current document) is ready? I
noticed that a DOMContentLoaded attached by content to the document, is not
fired at all. I guess that means that though the event is still
propagating, the handlers on the original doc have already been released.

Post by a***@yahoo.com
Why are document.location and window.location out of sync?

Are document and window.document equal?

No, (event.target === event.target.defaultView.document) is false,
event.target.defaultView.document.URL is "about:blank" while
event.target.URL is the original one.

[a***@yahoo.com]

Post by a***@yahoo.com

Post by Boris Zbarsky

Post by a***@yahoo.com
In appcontent.DOMContentLoaded for an iframe, which in an inline script
changes parent.location and then assigns its own location to
about:blank,
document.location is null, window.location is about:blank and document.URL
is the actual url.
Even though location has been changed before DOMContentLoaded, the
navigation presumably has not started

If document.location is null, then not only has navigation started but
the new document is already partway through being loaded and the old
document is not the current document in the window, I would think...
You can tell this also from the fact that window.location is about:blank.

event.target is still the old document. If the old document is (partially
or completely) gone, does it make sense to fire a DOMContentLoaded, whose
meaning is that the dom of the target (current document) is ready? I
noticed that a DOMContentLoaded attached by content to the document, is
not fired at all. I guess that means that though the event is still
propagating, the handlers on the original doc have already been released.

Post by Boris Zbarsky

Post by a***@yahoo.com
Why are document.location and window.location out of sync?

Are document and window.document equal?

No, (event.target === event.target.defaultView.document) is false,
event.target.defaultView.document.URL is "about:blank" while
event.target.URL is the original one.

So this indicates that the original doc has already been orphaned (unhooked
from the dom tree), if that's the case, does it not mean that
DOMContentLoaded should not be fired for it?

[Boris Zbarsky]

Post by a***@yahoo.com
If the old document is (partially
or completely) gone, does it make sense to fire a DOMContentLoaded

Good question. File a bug with a testcase, please?

-Boris

[a***@yahoo.com]

Post by Boris Zbarsky

Post by a***@yahoo.com
If the old document is (partially
or completely) gone, does it make sense to fire a DOMContentLoaded

Good question. File a bug with a testcase, please?

https://bugzilla.mozilla.org/show_bug.cgi?id=696885
DOMContentLoaded attached on appcontent, fires for an orphaned doc, already
replaced in the dom tree

[smaug]

Post by a***@yahoo.com
event.target is still the old document. If the old document is (partially
or completely) gone, does it make sense to fire a DOMContentLoaded, whose
meaning is that the dom of the target (current document) is ready?

Well, at the time your listener handles DOMContentLoaded, some other
DOMContentLoaded listener may have caused the window.document to change.


-Olli