Closed Bug 107806 Opened 23 years ago Closed 22 years ago

"alert me before downloading image" dialog locks mozilla

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 110112
Milestone:
mozilla1.0.1

People

(Reporter: chris+bugzilla, Assigned: danm.moz)

References

(
URL
)

Details

(Keywords: hang)

Attachments

(1 file)

Testcase for 107806
1.18 KB, text/html
Details 
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
Assignee: asa → morse
Keywords: hang
This is either a dup of bug 85846 or at least it's related to that bug.
Assignee: morse → danm
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.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
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).
Component: Browser-General → Event Handling
Attached file Testcase for 107806 — 
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
QA Contact: doronr → madhur
Target Milestone: --- → mozilla1.0.1
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
OS: Mac System 9.x → All
Hardware: Macintosh → 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.
Keywords: nsbeta1
QA Contact: madhur → rakeshmishra
Blocks: 138229
*** 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 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
QA Contact: rakeshmishra → trix
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: