From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.5+) Gecko/20011031 BuildID: 2001103104 Reproducible: Always Steps to Reproduce: 1. check "alert me before downloading image" 2. go to http://bbspot.com/ 3. say yes (and remember) to load image from bbspot.com 4. say no (and remember) to load image from rcm-images.amazon.com Actual Results: dialog does not close, mozilla stays locked in modal dialog Expected Results: dialog closes, page continues to load (I already had www.burstnet.com images blocked) The dialog buttons appear to be active -- I can click them and check/uncheck the remember checkbox -- but the dialog never does anything. I had to force-quit mozilla to get out. With "alert me before downloading image" off, the page loads fine.

I hit this bug again with a more recent build (2001-11-06) on www.arstechnica.com

I hit this bug again with the 2001-11-19 build As a workaround, I manually entered rcm-images.amazon.com 1F in cookperm.txt. This prevents the dialog from appearing and avoids the lockup.

->morse

This is either a dup of bug 85846 or at least it's related to that bug.

Morse: Hopefully it's similar to 85846, but the significant difference may be one of focus. In other cases where I suffered from the dialog flood, I could often repeatedly hit Esc to close them, even when I could not close the top one (at least that's what happened with the "Advance to next unread?" bug 97466). With this one, I only see one dialog pop up (with bug 97466 I could see all the dialogs popping up). But in fact there were just two images from that domain, so maybe I never saw the first one...

Confirmed using Mac/2001102011 (0.9.6). I allowed (remembering) an image from bbspot.com. I then allowed (remembering) an image from www.burstnet.net. Finally, I denied an image (remembering) from rcm-images.amazom.com, and the Confirm dialog failed to dismiss. It was necessary to force-quit Mozilla. This is a "focus hang" rather than an infinite loop or crash. (Maybe we need a "focus" keyword.)

This bug also occurs in Mozilla for MacOS X -- see http://bugzilla.mozilla.org/show_bug.cgi?id=119686 The ad banner scripts from rcm-images.amazon.com screw up Mac Mozilla something fierce.

*** Bug 119686 has been marked as a duplicate of this bug. ***

*** Bug 119236 has been marked as a duplicate of this bug. ***

Triaged to event handling as most likely location for the problem (which from comments, seems to be focus based). May not be completely correct, so please reassign if investigation shows it to be necessary, but its better than Browser General! Please note that this bug also affects MacOS X builds (the last two bugs I've just marked as duplicate).

Here is my testcase and analysis from bug 119686 (duplicate). 1) if you load moz-breaker.html from a remote web server then it DOES set off the image warning dialog box, and Mozilla FREEZES right there. Feel free to hit my copy at http://jhunix.hcf.jhu.edu/~fuy/moz-breaker.html 2) if you load moz-breaker.html locally using file:/// then it does NOT set off the image warning dialog box, and the page works. The remote images LOAD automatically, which strikes me as a security failure. 3) if you load moz-breaker.html from http://localhost (using OS X Apache) then it DOES set off the image warning dialog box, and the page WORKS. Your image loading preferences are honored (and added to the Image Permissions list if you checked the Remember box). p.s. Two other sites affected by this bug are http://www.mtgnews.com and http://asktog.com

i disagree with the component choice but will play along

http://www.powerpage.org (a Mac news site) is also affected. Google says there are about 900 others. http://www.google.com/search?as_epq=rcm-images.amazon.com

happens to me too on 0.9.9/Win98, OS/platform -> All

*** Bug 127866 has been marked as a duplicate of this bug. ***

*** Bug 124314 has been marked as a duplicate of this bug. ***

For the benefit of others who may be burned by this bug, but don't want to go mucking around their Mozilla config files, an easy workaround: 1. Disable Javascript (preferences:advanced:scripts and windows) 2. Go to any page using an ad from our favorite server (e.g. http://www.asktog.com/) 3. Tell Mozilla to block images from our favorite server, remembering the decision. It should work. Haven't tried it with accepting images instead, but I suspect it would work too. 4. Reenable Javascript and give your site a whirl Since the pref is already saved, Mozilla happily rejects the amazon images, and the day is won. (Or at least this works for me)

(sorry for the 5 comments in one day, but this one's good, I promise) I have a minimal testcase for this bug (that doesn't involve Amazon's servers, thank goodness). I haven't tried this testcase in the most recent nightly, but it breaks me in 0.9.9/Win98. Directions: 1. Make sure image permissions are activated, and go into your image manager and delete any standing permission for pantheon.yale.edu. 2. Go to http://pantheon.yale.edu/~al262/mozilla/107806/ . The code that makes this happen: --- index.html --- <html><head><title>Testcase for bug 107806</title></head> <body> <h1> Testcase for <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=107806">bug 107806</a> </h1> <script src="script.js" type="text/Javascript"></script> </body></html> --- script.js --- document.write("<img src=ant.jpg>");document.close(); You can go to http://rcm.amazon.com/e/cm?t=tog&l=rc1&p=5&o=1 (listed as the script source in Frankie's testcase) and verify that they use a similar construction.

On that testcase, clicking OK or cancel I get the following errors: JavaScript strict warning: chrome://global/content/bindings/dialog.xml#dialog._reallyDoButtonCommand() line 7: reference to undefined property window.close JavaScript strict warning: chrome://global/content/bindings/dialog.xml#dialog._reallyDoButtonCommand() line 7: reference to undefined property window.close JavaScript error: chrome://global/content/bindings/dialog.xml#dialog._reallyDoButtonCommand() line 7: window.close is not a function ccing hewitt since this seems like his kettle of fish.

As another note, at that point in the script: window === [object ChromeWindow] window.close === undefined Those are also the values at the beginning of the <dialog> constructor...

*** Bug 135306 has been marked as a duplicate of this bug. ***

nominating. This is very high visibility and makes the browser impossible to use if this alert is enabled.

*** Bug 138229 has been marked as a duplicate of this bug. ***

Re-posting my comment from bug 138229: http://czyborra.com/charsets/iso8859.html loads a hit counter graphic from http://wwwwbs.cs.tu-berlin.de/cgi/count/%5c~czyborra/charsets/ Mozilla (OS X trunk 2002041603) hangs upon presenting the image permission alert for the tu-berlin site. Everything except the main Mozilla menu cannot gain focus. This is different from the rcm-amazon freeze as follows: 1. The image is sent by a cgi (instead of Javascript) 2. The Quit button still works (instead of only Force Quit) 3. Upon Quit, Mozilla crashed.

*** Bug 142201 has been marked as a duplicate of this bug. ***

*** Bug 142806 has been marked as a duplicate of this bug. ***

I have this bug on the following URL: http://expo2.expeditors.com/expo/GGS/gGS.asp?TN=4051381394&Guest=snap I also have a screen shot if anyone needs it. To add some info, if I move the "locked" dialog box, I see a duplicate dialog, that can not be given focus.

*** Bug 144841 has been marked as a duplicate of this bug. ***

Build 2002051603 apparently has a fix for this bug -- "ask before loading an image" is disabled entirely. :-( I have posted bug 145051.

This bug should be closed. The entire image confirmation system was killed (removed from game, actually) at the end of bug 110112. When an equivalent feature is re-created in some distant future (see bug 146513 and bug 145690), it will not behave like this.

*** Bug 88559 has been marked as a duplicate of this bug. ***

What Frankie said. Bug 110112 is arguably the same bug. It was fixed, or the crash averted anyway, by disabling the entire image download alert mechanism. The problem is very deep seated and pretty much impossible to fix at the root level. Objections addressed, it looks like we've settled on keeping the 110112 fix and a hope of someday rewriting the feature (bug 146513). When that happens, it'll work differently. A new set of bugs will apply but this one won't. Closing as a duplicate of 110112. *** This bug has been marked as a duplicate of 110112 ***