Bug 13241 – onload fires before content is finished loading (woot.com)

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[William Lynch]

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.

[William Lynch]

And now it works fine... So nevermind.

[Matt Lilek]

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.

[Darin Adler]

In the log I see:

Unsafe JavaScript attempt to access frame with URL http://www.woot.com/ from frame with URL http://pagead2.googlesyndication.com/pagead/ads?client=ca-pub-2332856072838068&dt=1175324320101&format=300x250_as&output=html&channel=2981528485&url=http%3A%2F%2Fwww.woot.com%2F&color_bg=CECEC5&color_text=000000&color_link=4A6751&color_url=B35A1E&color_border=CECEC5&kw_type=broad&kw=Ultrex%20415994%20Travel%20Mug%20Coffee%20Maker&ad_type=text_image&ref=http%3A%2F%2Fbugs.webkit.org%2Fshow_bug.cgi%3Fid%3D13241&cc=77&u_h=1600&u_w=2560&u_ah=1574&u_aw=2560&u_cd=24&u_tz=-420&u_his=3&u_java=true&u_nplug=12&u_nmime=148. Domains must match.

So somehow the ad frame is mixing things up and confusing our cross-domain stuff.

[Matt Lilek]

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]

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]

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]

<rdar://problem/5126396>

[Darin Adler]

(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]

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".

(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]

I'm working on this.

[Geoffrey Garen]

Created attachment 15457 [details]
patch

[Maciej Stachowiak]

Comment on attachment 15457 [details]
patch

r=me

[Geoffrey Garen]

Committed revision 24148.