only loosely blocking, this may not even cause JS compatibility problems.

Consider as a low priority of after-enable bug.

I intercept http request & http response, I get the LoadContext and find out the inner window ID & outer window ID. The http request I intercepted is for a url to replace the current view, i.e. to replace the current page on the current tab, i.e. it will result in a new inner window. But when I intercept the request and the response, I still do not know its new inner window id, which can only be known with "content-document-global-created" event. The event sequence is http-on-modify-request http-on-examine-merged-response content-document-global-created If the page will not be replaced by the new http response (e.g. an image), then the LoadContext.associatedWindow gives the current window is good. But if the page is going to be replaced by the new http response (html page), I would hope the LoadContext.associatedWindow is a new window. Though before the response is really received, it is unnecessary to replace the current page with blank.

jack, your comment doesn't belong to this bug at all. This is about a nit change to nsILoadContext*Info* and not at all about nsILoadContext. BTW, I decided to close this bug as WONTFIX, I don't think we need any modifications to this interface.