1) Load http://arstechnica.com/reviews/apps/pogo-browser-beta-first-look.ars 2) Scroll down first screenshot, click it. A small window opens showing the image (http://media.arstechnica.com/news.media/PogoDock.jpg). It's 1920x1143, so it's scaled down. 3) Click in the far lower-right to switch from scaled-to-window to full size view. Click again anywhere to switch back to scaled-to-window view. 4) Oops, image is gone! Observations: * Things work fine in step 3 when clicking in the far *upper-left* of the window. It's only clicks towards the lower-right that cause the problem... Maybe something is getting confused with the change of coordinates between zoomed/non-zoomed views? * The window opened in step 2 seems to have a read-only location field, no toolbar, and no scroll bars are shown when the image is zoomed 1:1. This seems to be important; when the image is loaded in a normal tab everything works fine. Noming for blocking, since this kind of "open image in a small child window" seems to be fairly common (although I don't know how often it breaks like this).
Poked though the JS on the page to see how it's opening the child window. I can reproduce by just running the following from the JS Console: window.open('http://media.arstechnica.com/news.media/PogoDock.jpg', 'ars_img', 'resizable=yes,width=400,height=300'); Any large image will do: window.open(' http://www-pao.ksc.nasa.gov/kscpao/images/large/08pd0886.jpg', 'blah', 'resizable=yes,width=400,height=300');
I can reproduce this on a Linux FF3 nightly too. On Firefox 2 (OS X), step 3 from the comment 0 STR doesn't result in an empty window, the image is correctly shown 1:1... But it's actually broken, because you can't click again to zoom out, and resizing the window causes areas to be repainted white in a glitchy way.
Related to Bug 369370 ?