Closed Bug 74506 Opened 25 years ago Closed 25 years ago

enabling imglib2 has caused some pages to stop firing onload

Categories

(Core :: Graphics: ImageLib, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: jrgmorrison, Assigned: pavlov)

References

Details

(Keywords: perf, topperf, Whiteboard: [imglib])

Attachments

(1 file)

As libpr0n was enabled on each platform (first win32, then mac, then linux), the following mock pages used in the page load test began to fail to fire onload. These are URLs to a "static" of these pages, without the reloading javascript that drives the test. http://jrgm.mcom.com/perf/loadtime5/base/www.msn.com/index.html http://jrgm.mcom.com/perf/loadtime5/base/www.spinner.com/index.html http://jrgm.mcom.com/perf/loadtime5/base/www.zdnet.com_Gamespot.com/index.html http://jrgm.mcom.com/perf/loadtime5/base/www.tomshardware.com/index.html http://jrgm.mcom.com/perf/loadtime5/base/www.cnn.com/index.html http://jrgm.mcom.com/perf/loadtime5/base/www.voodooextreme.com/index.html Some of the above will fire onload on a second visit, or a reload of the page (msn.com and spinner.com in my test on win2k), but definitely none will fire onload on an initial visit. (Or, they may fire onload if left long enough, but the test cancels a load after waiting 45 seconds for 'load' event to fire). This is related to libpr0n, although it may be that it is just causing some other code paths in other modules to be exercised differently. At any rate, it would be good to sort out what is happening with these pages before a beta date.
Severity: normal → major
Keywords: nsbeta1, perf, topperf
Blocks: 74451
Whiteboard: [imglib]
Blocks: 72382
*** Bug 74648 has been marked as a duplicate of this bug. ***
this fixes gamespot and spinner. the rest are probably being hurt by the textfield bug.
Status: NEW → ASSIGNED
Blocks: 72378
need some hot r= and sr= action
Keywords: patch
I can sr= but would like an informed r= from someone who knows nsHTMLImageElement.cpp. Who would that guy be? /be
jst ?
I don't see how this would fix this bug (I'm not saying it doesn't, but I don't understand how), is the key to the fix here to hold on to the image request for the lifetime of images created with img = new Image(); img = 'someurl'? If so, do we really want that, I don't see where we'd use it after ::OnStopDecode(), except in ::GetComplete() where checking for it's existance should work, AFAIK. I don't see how mRequest->Cancel(NS_ERROR_FAILURE); in nsHTMLImageElement::SetSrcInner() could ever be called, the only place mRequest is set is sinside ::SetSrcInner() (below the call to mRequest->Cancel()) inside the if (mOwnerDocument) and every time ::SetSrcInner() is called and mOwnerDocument is non-null we set mOwnerDocument to null (NS_RELEASE(mOwnerDocument)), and mOwnerDocument is only initialized once per object (in ::Iniitialize()). (assuming I'm correct this means the old code (mLoader->RemoveFrame(this)) was moot too) I don't get it, key me in here, please?
*** Bug 73890 has been marked as a duplicate of this bug. ***
Priority: -- → P1
Target Milestone: --- → mozilla0.9
Depends on: 6074
As of Tuesday morning's builds, all of the URL's noted above are loading in the page loading test, as well as http://jrgm.mcom.com/perf/loadtime5/base/www.yahoo.com/index.html, which hadn't been loading for some period of time before the libpr0n stuff was switched on. I don't know the specific code change that caused this to start happening (but it may have been the change for bug 5569).
No longer depends on: 6074
fixed.
er, really fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
er, well it was fixed, but the last tinderbox cycle's page loading test showed it timing out on the above pages (with the exception of Gamespot).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Er, make that with the exception of Gamespot, and Spinner.com, for two cycles. Note also that the Yahoo.com page is timing out (which isn't part of the imglib2 change per se, since it had been around prior to that, but obviously is responding to the same change).
just checked in another fix.. its better once again.
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Verified fixed w98 build 2001051704 Verified fixed mac build 2001051705 Verified fixed linux build 2001051706
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: