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

<[email protected]> wrote in message 
news:[email protected]...
> "Boris Zbarsky" <[email protected]> wrote in message 
> news:[email protected]...
>> On 10/23/11 5:56 PM, [email protected] 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 
> 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.
>

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?