User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030221 Phoenix/0.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030221 Phoenix/0.5 I have reported this before here: http://www.mozillazine.org/forums/viewtopic.php?t=6546 What happens is that the test-case has an invisible iframe (width:0px;height:0px) and I have an xbl binding on an anchor in the document. The invisible iframe reloads itself every 20 seconds (from another domain). Now when you go to another site, then the invisible iframe still keeps reloading itself. I have minimized the case a lot, and I must use an xbl binding on the anchor and probably (not tested) style="width:0px;height:0px;" on the iframe in order to get the desired bug. The test case can be simplified further I guess (only necessary if this is not a duplicate). Reproducible: Always Steps to Reproduce: 1.Visit the above link. 2.Visit another site. 3.After 20 seconds you should see a reload of the invisible frame. This is done with a script:setTimeout('window.location.reload()',20000); Actual Results: See before. Expected Results: There should not remain anything from the site before.

jst? Sicking? Any idea what's up here?

Changed url to http://home.hccnet.nl/m.wargers/test/mozilla/sneakyframe2.htm Now the frame is reloading every 6 seconds and trying to do an alert. When visited another site, you get an exception after every 6 seconds: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowInternal.alert]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://home.hccnet.nl/m.wargers/test/mozilla/f0.html :: test :: line 8" data: no]

Sorry, the problem is much more simple. It seems that settimeout (and setinterval) is not killed in iframes. No need for xbl to reproduce the bug. Reassigning it to component:Browser-general. Fixing title and url: http://home.hccnet.nl/m.wargers/test/mozilla/sn.htm In normal frames the settimeout does get killed.

The reporter of bug 195620 (which should be duped to this one) suggests that this is a regression in the 'branching for 1.3' timeframe (although the build it has been reported on here is slightly older than that). Can anyone confirm this? Also, this should be moved to a more appropriate component and assignee (something under DOM or Javascript engine?). Also the OS should be all since I (and the reporter of bug 195620) see this on linux.

*** Bug 195620 has been marked as a duplicate of this bug. ***

yeah... This is pretty major (and could be a privacy or security issue).

I just filed a duplicate of this bug - in my case it manifested as an iframe continually reloading after I had visited a page once - this kept my demand-dial link up for a day or more - I'm still waiting for my ISP's bill for last month :-/ Since I'm on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030226, I'm marking this 'OS: all' Perhaps someone with sufficient privileges can mark this 'NEW'? ... Oops, midair collision: Boris already did the remarking while I was writing this comment ...

This definitely has security implications, making a 1.4a blocker and nominating for 1.3 (but drivers really want to be done with 1.3). It's always been a strict rule that when you leave a site you really leave and don't leave bits of code hanging around doing potentially nasty stuff. It's hinted that this might be a recent regression, can anyone pin down when? I don't see the problem with the URL link http://home.hccnet.nl/m.wargers/test/mozilla/sn.htm, but I do see the exceptions after leaving sneakytest2.htm. Closing the window seems to stop it, which is slightly better than having to close the entire browser.

After closing the window mentioned in my previous comment my browser went all wonky. Coincidence? (Missing chrome bits, mail was mostly non-responsive). Quitting didn't shut it down entirely, all the windows went away but the process was left running and had to be killed. No problems on the 1.0 branch, btw. Not much help in pinning down the regression, but it definitely is one.

Re comment #4: regarding the timeframe, unfortunately I really can't be more precise at the moment. I 'discovered' the problem when I noticed that my demand-dial link would not go down anymore under certain conditions. It turned out the the condition was 'Having visited http://www.aliendice.com/sivine/ , and then leaving Moz running'. This could well have gone on for some time before I discovered it. On the other hand, I visit this site regularly, and often leave the browser running afterwards - so I'd almost bet money that it couldn't have gone unnoticed for more than a week or so. Re comment #8: I definitely have to close Moz completely to stop the reloading at http://www.aliendice.com/sivine/ . Even if I close all Browser windows and only leave e.g. Mailnews open, I can see the HTTP exchange take place every 18 seconds (for details, pls. see duped bug 195620). Unfortunately, I'm a bit short on time at the moment, and can't D/L, install and test older versions - I only have my current trunk build available.

Hmm... this _seems_ to have broken between 2003-02-21-22 and 2003-02-22-05... (though testing this is somewhat imprecise, so I could be off....) bryner, jkeiser, could this be due to that mExplicitEventTarget leak? That seems to be the only checkin in that date range that could be responsible....

It was at least partially broken before then, my 2/20 build had the symptoms in comment 8 and 9. Since this bug's URL link didn't work on me after I left the page it looks like it regressed further on 2/21

Yeah, what I'm seeing is that we try to alert() 2-6 times on and off in builds going back to early January after page close. The date range I gave is when the "2-6" turned into "infinite" as far as I can tell... ccing aaronl too, since he did the last major work on keeping pages alive during page transitions....

Setting to blocking 1.3.

Gah! Ok, the problem is that we cancel timeouts and intervals when a frame/window is *unloaded*, but we never properly *unload* hidden iframe's! This is bad... I'm at a W3C meeting until Monday next week, but I'll see what I can do. Peterv, feel free to step in here if you get to this before I do, I'm guessing we need to "unload" an iframe's document in nsHTMLIFrameElement::SetDocument() when the document is set to null...

This should fix this, but someone should sanity check this and make sure this is really what we want. This will cause the moving of an iframe to cause a reload of the document it contains, not sure if that's cool or not... I'm unable to verify that this does the right thing, so someone (peterv?) needs to look into this and roll this into the tree if it must land before Monday next week.

hmm.. reloading on move sounds uncool to me. Couldn't you destroy the loader in the elements dtor instead? Though given the seriousness of this bug this is of course something we could live with for a limited time if nothing else

The frame loader is already destroyed in the iframe element's dtor, but apparently the iframe element is not destroyed right away (and you could hold it alive indefinately if you create a reference from the iframe window to the iframe element), so that's not good enough. We need more than that, and I realize my proposed fix is not ideal. What we really need is a nsIContent::DocumentUnloaded() or somesuch, but I don't think we want to go there for 1.3... Btw, peterv is not around to deal with this, and I'm unable to. If this needs landing today, someone needs to step up and do the testing, reviewing, approval requesting, and checking in.

er, is this really FIXED?

No.

Duh, exuse my phat fingers (or whatever happened there).

what we could do is to register as an nsIDocumentObserver, then the element would be notified when the document dies. I'll try to come up with a patch

I think i have a fix but i'm not sure how to test it? What is supposed to happen when i go to http://home.hccnet.nl/m.wargers/test/mozilla/sn.htm and what is not supposed to happen?

I *think* this patch should take care of this. However i'm not sure how to reproduce the bug so I havn't been able to test it. The patch is pretty safe so if it indeed fixes the bug i think it could be landed on the 1.3 branch. Unfortunatly I won't be able to drive this into the tree. It's 4am here and i'm leaving for the weekend tomorrow morning so someone else will have to shoulder that responsibility :(

DOH! I just realized that it is possible to work around that patch so if security is the issue then that patch won't close all holes. However if the main concern is odd behaviour then at least that patch should make things somewhat better so it might be worth landing on the 1.3 branch. Sorry guys, but i'll have to leave the investigations to you.

Johnny, can you take a look at Jonas' patch? We're getting really close to a release and this is the only bug we have still blocking.

jst: if we can't rely on the element going away I guess we can't rely on the document going away either, right?

Comment on attachment 116604 [details] [diff] [review] another attempt Right. This won't make things much, if at all, better. As I said earlier, we need a nsIContent::DocumentUnloaded() or somesuch to fix this the "real way", but I really don't think we want to go there for 1.3. I'd suggest taking my initial patch for 1.3, and then thinking about a better fix for 1.4.

Comment on attachment 116516 [details] [diff] [review] Destroy the frame loader when an iframe element's document is going away. I'm proposing this for 1.3 final, reviews?

Comment on attachment 116516 [details] [diff] [review] Destroy the frame loader when an iframe element's document is going away. ok, lets go with this for the branch. An easier way for trunk then nsIContent::DocumentUnloaded might be a combination of my patch and having a nsIDocumentObserver::DocumentUnloaded

Comment on attachment 116516 [details] [diff] [review] Destroy the frame loader when an iframe element's document is going away. a=asa (on behalf of drivers) for checkin to 1.3 branch. Please land this ASAP and put "fixed1.3" in the status whitebord when it's landed. Thanks.

Fix checked in on the 1.3 branch.

This fix appears to work using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030311 - neither of the testcases on this page continue to show signs of the script running after the page has been left.

Mass-reassigning bugs to dom_bugs@netscape.com

fixed 1.3, blocking 1.4a-, regression 1.4b?

Jonas, can you put this fix into the trunk while investigating a better fix for 1.5?

Is this still needed for 1.4?

I can't reprodue the original problem with one of the gtk2 builds from a couple of days ago (2003050209). When the test page is unloaded, the javascript alert no longer appears.

Indeed with this example I can't seem to reproduce it anymore: http://home.hccnet.nl/m.wargers/test/mozilla/sn.htm This one on the other hand still reproduces the problem: http://home.hccnet.nl/m.wargers/test/mozilla/sneakyframe2.htm The same js-error every 6 seconds. I used: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/2003050211

Comment on attachment 116516 [details] [diff] [review] Destroy the frame loader when an iframe element's document is going away. I think we should definately take this fix for 1.4b, if not for that, then for 1.4 final.

Comment on attachment 116516 [details] [diff] [review] Destroy the frame loader when an iframe element's document is going away. 1.4b is out. a=asa (on behalf of drivers) for checkin to 1.4.

Fix checked in on the trunk. Leaving bug open for further work on this problem.

*** Bug 179287 has been marked as a duplicate of this bug. ***

I'm marking this worksforme, it's probably fixed by now, one way or another.