Bug 13241 - onload fires before content is finished loading (woot.com)
Summary: onload fires before content is finished loading (woot.com)
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh OS X 10.4
: P1 Normal
Assignee: Geoffrey Garen
URL: http://woot.com
Keywords: HasReduction, InRadar
Depends on:
Blocks:
 
Reported: 2007-03-30 23:01 PDT by William Lynch
Modified: 2007-07-10 09:28 PDT (History)
5 users (show)

See Also:


Attachments
Reduction (701 bytes, text/html)
2007-04-02 20:46 PDT, Matt Lilek
no flags Details
patch (57.50 KB, patch)
2007-07-09 23:02 PDT, Geoffrey Garen
mjs: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description William Lynch 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.
Comment 1 William Lynch 2007-03-30 23:02:48 PDT
And now it works fine... So nevermind.
Comment 2 Matt Lilek 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.
Comment 4 Matt Lilek 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.
Comment 5 Dave Hyatt 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.
Comment 6 Dave Hyatt 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.

Comment 7 Darin Adler 2007-04-11 02:11:51 PDT
<rdar://problem/5126396>
Comment 8 Darin Adler 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.
Comment 9 Maxime BRITTO 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".

Comment 10 mitz 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.
Comment 11 Geoffrey Garen 2007-07-06 12:30:42 PDT
I'm working on this.
Comment 12 Geoffrey Garen 2007-07-09 23:02:49 PDT
Created attachment 15457 [details]
patch
Comment 13 Maciej Stachowiak 2007-07-10 02:20:40 PDT
Comment on attachment 15457 [details]
patch

r=me
Comment 14 Geoffrey Garen 2007-07-10 09:28:38 PDT
Committed revision 24148.