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.
And now it works fine... So nevermind.
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.
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.
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.
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.
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.
<rdar://problem/5126396>
(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.
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.
I'm working on this.
Created attachment 15457 [details] patch
Comment on attachment 15457 [details] patch r=me
Committed revision 24148.