info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Is null document.location expected in this case or a bug?
111 views
Skip to first unread message
al...@yahoo.com
Oct 23, 2011, 5:56:26 PM10/23/11
to
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?
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
Oct 23, 2011, 8:14:51 PM10/23/11
to
On 10/23/11 5:56 PM, al...@yahoo.com wrote:
> 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
> 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
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.
> Why are document.location and window.location out of sync?
-Boris
al...@yahoo.com
Oct 24, 2011, 1:49:07 AM10/24/11
to
"Boris Zbarsky" <bzba...@mit.edu> wrote in message
news:7_6dnV-ziL9mMDnT...@mozilla.org...
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.
>
>> 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.
news:7_6dnV-ziL9mMDnT...@mozilla.org...
> On 10/23/11 5:56 PM, al...@yahoo.com wrote:
>> 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
>> 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.
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.
>
>> Why are document.location and window.location out of sync?
>
> Are document and window.document equal?
>
event.target.defaultView.document.URL is "about:blank" while
event.target.URL is the original one.
al...@yahoo.com
Oct 24, 2011, 2:01:37 AM10/24/11
to
<al...@yahoo.com> wrote in message
news:C-GdnRSeVbSnYTnT...@mozilla.org...
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?
news:C-GdnRSeVbSnYTnT...@mozilla.org...
from the dom tree), if that's the case, does it not mean that
DOMContentLoaded should not be fired for it?
Boris Zbarsky
Oct 24, 2011, 9:06:09 AM10/24/11
to
On 10/24/11 1:49 AM, al...@yahoo.com wrote:
> 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?
> If the old document is (partially
> or completely) gone, does it make sense to fire a DOMContentLoaded
-Boris
smaug
Oct 24, 2011, 4:05:56 PM10/24/11
to al...@yahoo.com
On 10/24/2011 08:49 AM, al...@yahoo.com wrote:
> 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
> 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?
DOMContentLoaded listener may have caused the window.document to change.
-Olli
al...@yahoo.com
Oct 24, 2011, 5:27:05 PM10/24/11
to
news:lNKdnYgFH8tc_zjT...@mozilla.org...
https://bugzilla.mozilla.org/show_bug.cgi?id=696885
DOMContentLoaded attached on appcontent, fires for an orphaned doc, already
replaced in the dom tree
DOMContentLoaded attached on appcontent, fires for an orphaned doc, already
replaced in the dom tree
0 new messages