Closed Bug 194994 Opened 21 years ago Closed 13 years ago

settimeout and setinterval not killed in iframe after visit

Categories

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

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: martijn.martijn, Unassigned)

References

()

Details

(Keywords: regression, Whiteboard: fixed1.3, fixed1.4)

Attachments

(1 file, 1 obsolete file)

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.
Component: XBL → Browser-General
Summary: Frame remains in window after one has visited other sites → settimeout and setinterval not killed in iframe after visit
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).
Assignee: hyatt → jst
Status: UNCONFIRMED → NEW
Component: Browser-General → DOM Level 0
Ever confirmed: true
Flags: blocking1.4a?
OS: Windows XP → All
QA Contact: ian → ashishbhatt
Hardware: PC → All
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.
Flags: blocking1.4a?
Flags: blocking1.4a+
Flags: blocking1.3?
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.
Keywords: regression
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. 
Flags: blocking1.3? → blocking1.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...
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.3final
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.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
er, is this really FIXED?
No.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Duh, exuse my phat fingers (or whatever happened there).
Status: REOPENED → ASSIGNED
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?
Attached patch another attempt (obsolete) — Splinter Review
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 :(
Attachment #116516 - Attachment is obsolete: true
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.
Attachment #116604 - Attachment is obsolete: true
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?
Attachment #116516 - Attachment is obsolete: false
Attachment #116516 - Flags: superreview?(peterv)
Attachment #116516 - Flags: review?(bugmail)
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
Attachment #116516 - Flags: review?(bugmail) → review+
Attachment #116516 - Flags: superreview?(peterv) → superreview+
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.
Attachment #116516 - Flags: approval1.3+
Fix checked in on the 1.3 branch.
Whiteboard: fixed1.3
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
Assignee: jst → dom_bugs
Status: ASSIGNED → NEW
Flags: blocking1.4a+ → blocking1.4a-
fixed 1.3, blocking 1.4a-, regression 1.4b?
Flags: blocking1.4b?
Flags: blocking1.4?
Flags: blocking1.4b? → blocking1.4b-
Target Milestone: mozilla1.3final → ---
Jonas, can you put this fix into the trunk while investigating a better fix for 1.5?
Flags: blocking1.4? → blocking1.4+
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.
Attachment #116516 - Flags: approval1.4b?
Attachment #116516 - Flags: approval1.4?
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.
Attachment #116516 - Flags: approval1.4b?
Attachment #116516 - Flags: approval1.4?
Attachment #116516 - Flags: approval1.4+
Fix checked in on the trunk. Leaving bug open for further work on this problem.
Whiteboard: fixed1.3 → fixed1.3, fixed1.4
Flags: blocking1.4+
*** Bug 179287 has been marked as a duplicate of this bug. ***
Assignee: general → nobody
QA Contact: ashshbhatt → general
I'm marking this worksforme, it's probably fixed by now, one way or another.
Status: NEW → RESOLVED
Closed: 21 years ago13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: