Closed Bug 840151 Opened 11 years ago Closed 11 years ago

dom-window-destroyed notification is fake?

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Version:
18 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: jackiszhp, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130201185534

Steps to reproduce:

My intention is to maintain a map between the document url & the tab/window.

I observe dom-window-destroyed & http-on-examine-response.
when I observed http-on-examine-response, I find its associated window.
   if http url is not window.location.href, I discard it since it is loading images etc.
   when I found one, I logged it.
when I observed dom-window-destroyed, I also logged it.
   and I try to find whether the window is mapped, if yes, I remove the map item.



Actual results:

during firefox start,
I found that there are 5 dom-window-destroyed notification.
 dom ContentWindow notFound
 dom ContentWindow notFound
 dom notContentWindow&notBrowserWindow  notFound
 dom notContentWindow&notBrowserWindow notFound
 dom notContentWindow&notBrowserWindow notFound
Of course, I did not close any window or tab.
found or not: I try to find the window from the map between the url & the content window.
contentWindow, browserWindow: I try to find out what kind of window it is.


when I load a simple web page.
I saw the log:
  add:http://h.jackiszhp.info/ac/hello.html
  dom contentWindow found & deleted:http://h.jackiszhp.info/ac/hello.html
Of course, I did not close any window or tab.

If I do not observer dom-window-destroyed, then the map item will not be deleted.
with the content webpage window, I can find the map item.

So it seems that I received some fake dom destroyed notification.
or I just do not understand the mechanism.
During loading of a web page, 
for every http request, there will be a domwindow to be destroyed.



Expected results:

To load a resource, there should not involve a dom window to be destroyed.
a related stuff: Bug 321282 - Loading Gmail leaks six DOMWindows 
but it was not well-explained.

    if (aTopic === 'http-on-examine-response') {
      //do not get call when it was cached.
      try {
        var theWin = this.getWindowForRequest(aSubject);
        if (theWin !== null) {
          var url=httpCI.documentURI;
          if (theWin.location.href !== url.spec) {
            return;
          }
          this.log+="   add:"+url.spec;
          this.onWindowChange(theWin, url);
        }
      } catch (e) {
        this.winStart.alert(e);
      }
    } else if (aTopic === "dom-window-destroyed") {
      this.onWindowDestroyed(aSubject, "dom");
    }
  },
  onWindowChange: function(win, url) {
    var iloc = this.wins.indexOf(win);
    if (iloc === -1) {
      iloc = this.wins.length;
      this.wins.push(win);
    }
    this.urls[iloc] = url;
  },
  onWindowDestroyed: function(win) {
    var iloc = this.wins.indexOf(win);
    var found = iloc !== -1;
    this.log +=" dom " + this.whatWindow(win)+" "+found;
    if (found) {
      this.wins.splice(iloc, 1);
      var url=this.urls.splice(iloc, 1);
      this.log +=" deleted:"+url.spec;
    } else {
    }
  }
Component: Untriaged → Tabbed Browser
Keywords: dom0, dom1, dom2
Keywords: dom0, dom1, dom2
Component: Tabbed Browser → DOM
Product: Firefox → Core
dom-window-destroyed is called on inner windows.  During pageload in a new tab or new iframe there is often a temporary about:blank inner window triggered by script access before the real page has started loading; it then gets destroyed when the real page starts loading.

Are you sure that this is not what you're seeing?

Note that the location is the location of the _outer_ window.  So if you log the location in dom-window-destroyed you we will get the location of the current inner, not of the inner that is being destroyed (which is almos certainly different).
Thank you for your responding.

for dom-window-destroyed notification, I did not touch window.location property. I did check window.location property for http-on-examine-response notification.

I thought, dom window will be created (when new page load) and destroyed(when old page replaced by new page). My purpose to prepare the IP related stuff to serve some callers.
So when a new page load, I get its IP information(with http notification), when a page is unloaded(with dom destroyed), I destroy its IP information.

It is also about timing, I was expecting received dom-destroyed before http-examine. If this could be true, even the window associated with dom-destroyed message is never destroyed, the above idea should work.
but i received dom-destroyed after http-examine, so I prepared IP stuff, then delete it.

By the way, this is for my addon IP.
you can get the whole thing from mozilla:
https://addons.mozilla.org/en-US/firefox/addon/ip-address/

it is small, and if you do not want, you do not have to install at the first place,
get it, and you can open it to see all the source. Once you checked and confirm there is no malicious stuff, you can installed, and to do some test.
and you can also view the source here:
http://www.jackiszhp.info/tech/addon.IP.html

Thank you for your time and your effort to put this right. I hope every browser can provide this feature (provide local IP address to unprivileged web page when the user permits, and alwasy provide server IP address when the web page needs it).
> It is also about timing, I was expecting received dom-destroyed before http-examine.

The new window is always created before the old window is destroyed.  And http-on-examine-response comes before the new window has been created.

At this point, I'm really not clear on what the bug is about.  I see the code touching window.location in on-examine-response; at that point the location is the location of the _old_ page, typically.
"for dom-window-destroyed notification, I did NOT touch window.location property. I did check window.location property for http-on-examine-response notification."

As I test, I found that with http-on-examin notification, the location  
theWin.location.href === httpCI.documentURI.spec
while theWin is the window associated with the httpCI(httpChannelInternal)
so it is new, not old.

What is the bug?
#1. Originally, I thought it is weird that I just start my firefox, I received 5 dom-destroyed notification. OK. with time, I can accept this as not bug, but a design.

#2. about the timing
>>It is also about timing, I was expecting received dom-destroyed before http-examine.
>The new window is always created before the old window is destroyed.  
>And http-on-examine-response comes before the new window has been created.
As you state, with http-on-examine notification, I am not able to find the right window since new window has not been created yet.

Then for the purpose of this addon which is to get the IPs & ports of the current window (no matter top level window or inside document window), 
any idea on when to get the IPs and when to destroy the information?

Originally, I intended to get it with http-on-examine notification, and destroyed it when dom window destroyed. since timing is designed another way around (as you stated above), my work around solution is not to use dom-destroyed, instead, I destroy them in a later time (triggered by something else) by checking whether the concerning window is belong to the set of content window. if not, then destroy it.

Thank you for your time and effort to look at this.
> theWin.location.href === httpCI.documentURI.spec

Sure.  Both are the old page in on-examine-response.

> while theWin is the window associated with the httpCI(httpChannelInternal)

Determined how, exactly?  If you did it in the obvious ways, it's the window that was there when the load started (because there is no other window to be had yet).

> I received 5 dom-destroyed notification.

Transient about:blank, almost certainly.

How are you getting the IP in on-examine-response?  Seems like the right way to do things would be to get the IP when the window is created, if you can, and destroy in window destroyed.
>> theWin.location.href === httpCI.documentURI.spec
>Sure.  Both are the old page in on-examine-response.
I found that it behaves as follows.
i start firefox, blank page, the url should be about:blank.
then I load http://h.jackiszhp.info/ac/hello.html
I received http-on-examine notification, and the url is http://h.jackiszhp.info/ac/hello.html.
it suggests the url is new, not old (about:blank).

if I do another url, when I receive http-on-examine, it is also the new url.

the window associated with the httpCI(httpChannelInternal) is determined by this method:
while the request is the http channel for the http-on-examine notification.
var httpC = aSubject.QueryInterface(Components.interfaces.nsIHttpChannel);

  getWindowForRequest: function(request) {
    if (request instanceof Components.interfaces.nsIRequest) {
      try {
        if (request.notificationCallbacks) {
          return request.notificationCallbacks
                  .getInterface(Components.interfaces.nsILoadContext)
                  .associatedWindow;
        }
      } catch (e) {
      }
      try {
        if (request.loadGroup && request.loadGroup.notificationCallbacks) {
          return request.loadGroup.notificationCallbacks
                  .getInterface(Components.interfaces.nsILoadContext)
                  .associatedWindow;
        }
      } catch (e) {
      }
    }
    return null;
  },


>How are you getting the IP in on-examine-response?
with http-on-examine notification, I can get nsIHttpChannelInternal
var httpCI = aSubject.QueryInterface(Components.interfaces.nsIHttpChannelInternal);

httpCI has the IP information. For this question, I am wondering whether you do not know about this, or you are doubting this method.

I think the right way to get IP is here, i.e. when the web browser get the content from the internet, what IP & port is used. Not in any other time, not came from another round of DNS lookup. and for http-on-cached content, just tell the caller, it is from cache, so no IP information is available. for http-on-merged, IP is also available.

when you said "to get the IP when the window is created"? I do not know how to achieve this? would you please elaborate it.

Thank you for discussion.
If you can take over this little addon, it will be even greater. I just want to see such feature is available.
> I received http-on-examine notification, and the url is http://h.jackiszhp.info/ac/hello.html.

Which exact url?  The one on the channel, the one on some window, the one on some document, or the one on some docshell?

> getWindowForRequest

OK.  So that will return the outer window: the thing the navigation happens in.  That contains the old page at the point when on-examine-response for the new pageload happens, but then later contains the new page.

> For this question, I am wondering whether you do not know about this

Ah, no, I did not know we exposed IP info on nsIHttpChannelInternal.  I also didn't know your httpCI was an nsIHttpChannelInternal (though now I see you sort of unclearly mentioned that in comment 5).

So one thing you can do is just get the currentDocumentChannel from a docshell for a given window if you want the nsIHttpChannelInternal that was used to load the document that's being shown in that window right then.  You can do this when the window is created, I would think (see the "content-document-global-created" observer notification).

In any case, the .documentURI of an nsIHttpChannelInternal is the same as the URI if it's a document load.  So I would expect your .documentURI to show the new thing.  But I would certainly not expect theWin.location.href to match it in that case.
With all these information, now I see you are really something!

>> I received http-on-examine notification, and 
>>the url is http://h.jackiszhp.info/ac/hello.html.
>Which exact url?  
>The one on the channel, 
>the one on some window, 
>the one on some document, 
>or the one on some docshell?
what I meant is for the transit from about:blank to hello.html, when I received the http-on-examine, the url is hello.html. and also can match the associated window.location.

I am not familiar with firefox(just started to dig into it because the addon postMSG and addon IP), so I did not know what docshell is.
I just checked content-document-global-created. 
aSubject is the dom window, and data is the scheme+host.
and I really do not know how to get ip info from dom window?
>get the currentDocumentChannel from a docshell?
how to get the docshell? I do not exactly know how to do several interface query to get it. given the dochshell, how to get the currentDocumentChannel? 
would you please elaborate this? appreciated.

>But I would certainly not expect theWin.location.href to match it in that case.
when they do not match, I thought it is loading an inside image, or load script, css etc, so I just ignore the http-on-examine.
          if (theWin.location.href !== httpCI.documentURI.spec) {
            return;
          }
I will take the IP info only when they match.
I just went to check, and found that you are right. 
when the page is little, i get only on http-on-examine notification, I guess I ignored the 1st such notification. so my original implementation works only when the page gives several http-on-examine notification. Glad to know how I got it wrong.
> and I really do not know how to get ip info from dom window?

  window.QueryInterface(Components.interfaces.nsIInterfaceRequestor)
        .getInterface(Components.interfaces.nsIWebNavigation)
        .QueryInterface(Components.interfaces.nsIDocShell)
        .currentDocumentChannel

will give you a channel.  You can then QI to nsIHttpChannelInternal and ask it whatever you want.

> when they do not match, I thought it is loading an inside image, or load script, css etc

Those are the cases when I'd expect the window's location and the documentURI.spec to match, actually, since the former is the current location of the window and the latter is the URI of the document that started the load, or will result from the load in the case of document loads.
I will do as you suggested. 
Thank you for the help. Without your helpful information, it will never get right!

I guess so this bug report is not real. you can close it. sorry about this.
Not a problem.  Good luck!
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.