Closed
Bug 178829
Opened 22 years ago
Closed 21 years ago
infinite loop when image onload contain selfreload script
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: oshpack, Assigned: rpotts)
Details
Attachments
(1 file)
597 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
try <img src='foo.gif' onload='this.src="foo2.gif"'>
Reproducible: Always
Steps to Reproduce:
Actual Results:
Infinite loop with frozen browser
I understand, what this code is incorrect, because after image loading it's fire
onload event, which reload image and fire event again.
![]() |
||
Comment 1•22 years ago
|
||
dup of the "police infinite loops" bug?
Reporter | ||
Comment 2•22 years ago
|
||
Yes.
note: many webcams legitamately use this sort of technique to achieve a
"streaming" effect.
Does it really freeze the browser?
Reporter | ||
Comment 4•22 years ago
|
||
Yes.
Mozilla permanently have occupied the memory and use 100% cpu time.
Particularly when image are local arranged.
Comment 7•22 years ago
|
||
Comment 8•22 years ago
|
||
The testcase I just attached shows this problem by creating an image and setting
the src of that image in its onload handler (but only 200 times so we don't lock
up mozilla).
This is really not a bug in mozilla though. Well, in a way it is, but IE has the
same problem, only it's not as severe. The way mozilla handles onload images is
different than how IE does it. We fire the onload event almost (through a
PLEvent, and we do so after the image request has been pulled out of the
loadgroup), and then we initiate a new load for the new (or same, really) image.
This means that in mozilla we'll load the document, load the initial url and
fire the image onload (and then possibly do the same for the new image that's
loaded from the image onload) and then fire the document's onload handler; then
we'll continue and load the image, fire the onload, load the image, fire the
onload, and so on... In doing that, we're starving the event Q and that's why it
appears as if mozilla locks up.
In IE it loads the document, loads the image, fires the onload, starts loading
the new image, fires it's onload, starts loading that image again, and fires the
onload and so on... All this is happening before the document's onload event is
fired, and the throbber is spinning all the time. IE remains responcive though,
so they're using lower priority events for driving this in IE.
So it seems to me that what we need to do is to put a dummy request in the
document's load group when we start loading an image, and we'll need to keep
that loadgroup in there untill the image's onload is fired. In addition, we
should also use an idle event (doesn't seem like PLEvent can do that, must we
use a 0ms timer? Eek!) to keep mozilla responsive while we're reloading this
image over and over.
Bottom line here is though, the testcase is broken, even if we fix this, you
won't want to do what you're doing here...
Rick, I'm giving this to you, if you can have a look at this then please do :-)
If not, pass it back.
Assignee: jst → rpotts
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
![]() |
||
Comment 9•22 years ago
|
||
So... is this still a problem after March 20th?
Comment 10•21 years ago
|
||
Well, I don't get a frozen browser with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040514
Not with the testcase, or with this code (which infinitely loops):
<html><body>
<script>
function foo(img)
{ img.src="http://bugzilla.mozilla.org/ant.jpg"; }
</script>
<img src=http://mozilla.org/images/mozilla-banner.gif onload='foo(this)'>
</body>
With this code, I get a CPU load of 40% (600MHz Duron)
So the problem seems to be fixed.
![]() |
||
Comment 11•21 years ago
|
||
Marking worksforme. Jst fixed this a long time back.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•