Re: XUL DOMContentLoaded - can't find anything about the propertoes of the returned event

"R.Wieser" <[email protected]> Tue, 26 Jan 2021 16:53:33 +0100
Newsgroups gmane.comp.mozilla.general
Message-ID <[email protected]>
Dave,

> Perhaps event.target will refer to the document itself,

After having looked at a "dump" of that event argument (which resulted in a 
set of properties and functions) I started to realize that too.

> Here on 76:
> document.readyState > "complete"

I've not tested it yet, but DOMContentLoaded should fire before all 
resources are received.  So, before the whole fetch has completed.

> But the status you want is not a property of the document.
> In the current APIs it's a property of the response object:
> <https://developer.mozilla.org/en-US/docs/Web/API/Response>
> which is the result of fetching a file.

I noticed that response object too, but have not seen anything which will 
retrieve it for the page which caused  DOMContentLoaded to be fired.

> What you want is the status of the first GET, the one that corresponds to 
> the URL.

Correct.   Though at some time I might try to I store a list of all the 
"failed" responses together with the resource name, and show them in the 
tooltip (got the idea from how GreaseMonkey uses it).

> How to get from the document object to the response object
> of the original GET? I don't know. I suspect you can't.

Thats what I'm trying to figure out. :-)

> I suspect you can't. And anyway, you can't do it in a background
> script in 52 because of that bug.

That crossed my mind too, but have to try anyway.   I would feel like a fool 
if I didn't try, and in some years on would read that it was indeed 
possible.

> I unpacked the old live headers addon to see how it got responses.

I've unpacked and inspected a few myself too but have not thought of that 
one.  Good one.

I'm not at all familiar with this stuff, but I suspect
> that it uses nsIWebProgressListener to get the headers:
> <https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIWebProgressListener>
>
> I wouldn't go there!

If thats the only way to go than at least I have to take a peek, sorry. :-)

Thanks.

Whoops, FF 15 ?   The question is if that will still work for FF 52 ....

Regards,
Rudy Wieser