RESOLVED FIXED 13241
onload fires before content is finished loading (woot.com)
https://bugs.webkit.org/show_bug.cgi?id=13241
Summary onload fires before content is finished loading (woot.com)
William Lynch
Reported 2007-03-30 23:01:06 PDT
In the current safari, if you goto www.woot.com, and click on their product image, it will resize correctly to fit the image. However, this does not happen in the current nightly. I get a 50x50 pixel window (or so) Using Intel Mac OS X 10.4.9 with all available patches.
Attachments
Reduction (701 bytes, text/html)
2007-04-02 20:46 PDT, Matt Lilek
no flags
patch (57.50 KB, patch)
2007-07-09 23:02 PDT, Geoffrey Garen
mjs: review+
William Lynch
Comment 1 2007-03-30 23:02:48 PDT
And now it works fine... So nevermind.
Matt Lilek
Comment 2 2007-03-30 23:34:11 PDT
Reopening as I can reproduce this. Only seems to happen when the page is not in the cache as clearing it causes this every time. The image loads in the new window but is never resized the first time you load it.
Matt Lilek
Comment 4 2007-04-02 20:46:19 PDT
Created attachment 13931 [details] Reduction This isn't a regression after all, nor a cross domain issue. Woot.com opens a blank window then fills it with content. The resize function is called on onload, but onload fires before the image in the window is finished loading so when the image size is queried, it returns 0. When you try this again, the image is in the cache and it all works fine. You'll probably need to clear your cache for this reduction to work as it uses an image from webkit.org.
Dave Hyatt
Comment 5 2007-04-02 21:46:58 PDT
I verified that in fact the image is coming in after the onload. That makes this a very serious bug, since it is critical that onload be correct. Elevating priority to P1.
Dave Hyatt
Comment 6 2007-04-02 21:53:34 PDT
document.close() is super super busted. We call through to implicitClose() in Document, which fires the onload without checking much of anything. document.close() should != our concept of close(), so I think somebody got confused here.
Darin Adler
Comment 7 2007-04-11 02:11:51 PDT
Darin Adler
Comment 8 2007-05-13 12:13:47 PDT
(In reply to comment #6) > document.close() is super super busted. We call through to implicitClose() in > Document, which fires the onload without checking much of anything. > document.close() should != our concept of close(), so I think somebody got > confused here. Given our approach for DOM, we want document.close() to be Document::close. So "our concept of close()" needs to have a different function name.
Maxime BRITTO
Comment 9 2007-06-26 08:50:38 PDT
On Safari 3.0b, Mac OS 10.4.9 and Webkit r23789, webkit crashes when trying to click on the product image (www.woot.com) or on the test case. Debugger Console log : Program loaded. sharedlibrary apply-load-rules all Attaching to program: `/Applications/Safari.app/Contents/MacOS/Safari', process 7802. warning: Can't find LC_SEGMENT.__DATA.__data section in symbol file warning: internal error: no C/C++ fundamental type 1 warning: internal error: no C/C++ fundamental type 1 (gdb) continue Program received signal: "EXC_BAD_ACCESS".
mitz
Comment 10 2007-07-03 14:23:54 PDT
(In reply to comment #9) > On Safari 3.0b, Mac OS 10.4.9 and Webkit r23789, webkit crashes when trying to > click on the product image (www.woot.com) or on the test case. That's bug 14425.
Geoffrey Garen
Comment 11 2007-07-06 12:30:42 PDT
I'm working on this.
Geoffrey Garen
Comment 12 2007-07-09 23:02:49 PDT
Maciej Stachowiak
Comment 13 2007-07-10 02:20:40 PDT
Comment on attachment 15457 [details] patch r=me
Geoffrey Garen
Comment 14 2007-07-10 09:28:38 PDT
Committed revision 24148.
Note You need to log in before you can comment on or make changes to this bug.