Closed Bug 436473 Opened 12 years ago Closed 11 years ago

firefox hangs if cookie ask permission to set whilst save target as dialog is open (image)

Categories

(Core :: Widget: Cocoa, defect, P1, critical)

PowerPC
Mac OS X
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: dave_street, Assigned: smichaud)

References

Details

(Keywords: hang)

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0

when cookies are set to ask "every time" firefox crashes if save target as (image) dialog is open and a cookie requests permission to set.

Reproducible: Always

Steps to Reproduce:
1.set cookies to ask everytime
2.load a page with an image
3.in another tab load another page with cookies
4.try to save the image in the first tab before the cookies from the other page load
5.crash now occurs on my system

Actual Results:  
Firefox freezes (spinning umbrella) and firefox must be closed using force quit

Expected Results:  
allowed image to be saved and then be able to manage the cookie request

no script plugin in use
Hardware: PC → Macintosh
Version: unspecified → 3.0 Branch
can you use sampler.app (from activitymonitor.app) to get a sample and attach the *text* version?
Keywords: hang, stackwanted
Summary: firefox crashes if cookie ask permision to set whilst save target as dialog is open (image) → firefox hangs if cookie ask permission to set whilst save target as dialog is open (image)
This is _really_ hard to reproduce, but I've managed to find a way
that "works" about one time in four.

1) Set "Cookies : Keep Until" to "ask me every time".

2) Visit a very noisy site (one that's slow to load) that also asks to
   set a lot of cookies.  I used http://www.vg.no.

3) As the page is loading, right-click somewhere on the page and
   choose "Save Page As".  If you manage to bring up a "Save As"
   dialog (OS modal) just before a (browser modal) "the site xxx wants
   to set another cookie" dialog appears, you'll see the hang.

   You'll find that if you've got a context menu open but haven't yet
   had time to choose the "Save	Page As" item, you can dismiss the
   "wants to set another cookie" dialog	by hitting Enter (and thereby
   gain more time to open the "Save As"	dialog before the next "want
   to set another cookie" dialog appears.

   Otherwise you'll need to reload the page and try again.  Before you
   do this, you should go into the Cookie Manager and remove all
   cookies that were set in your previous attempts to load
   http://www.vg.no (or whatever page you're testing with).  You may
   also need to remove sites from the Exceptions "allow" list that
   were added as you loaded http://www.vg.no.

In my next comment I'll post a gdb stack trace made during a hang.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Here's a gdb trace made after a hang, made using a build with debug
symbols (equivalent to today's 1.9.0 branch nightly).

The problem is visible in thread 1, and seems to result from an
attempt to display a browser-modal dialog (the "wants to set another
cookie" dialog) while an OS-modal dialog (the "Save As" dialog) is
still open.

This problem may also exist on other platforms -- I haven't tested,
and would appreciate it if others did.

But the	specific problem illustrated in	thread 1 of my trace is
probably OS-X-specific.  And I hope to find an OS-X-specific solution
for it.

(I'm marking this P3 because (being so hard to reproduce) I suspect
not too many people see it.  If I turn out to be wrong, I'll raise the
priority.)
I'm marking this qawanted to request tests on other platforms.
Keywords: stackwantedqawanted
Flags: wanted1.9.0.x?
Priority: -- → P3
Component: File Handling → Widget
Product: Firefox → Core
QA Contact: file.handling → general
Version: 3.0 Branch → Trunk
Flags: wanted1.9.0.x? → wanted1.9.0.x+
Duplicate of this bug: 440560
Duplicate of this bug: 442442
Bug 442442 contains useful information, and is much easier to
reproduce than this bug.  So I'm raising this bug's priority.

But even bug 442442 is probably seldom encountered, so I'm setting the
priority to P2.
Priority: P3 → P2
Even if variants happen on other platforms, this specific bug is a Cocoa widgets bug.
Assignee: nobody → joshmoz
Component: Widget → Widget: Cocoa
QA Contact: general → cocoa
Assignee: joshmoz → smichaud
Keywords: qawanted
Priority: P2 → P1
Attached patch Fix (obsolete) (deleted) — Splinter Review
After several false starts, here's a patch that fixes this bug.

I've tested it against the (easily reproduced) STRs of bug 442442 and
bug 426701.  Next week I'll test it against this bug's STR (which is
much harder to reproduce).

A tryserver build will follow in an hour or so.
Attachment #341705 - Flags: review?(joshmoz)
Comment on attachment 341705 [details] [diff] [review]
Fix

The patch needs more work to deal properly with nesting of app-modal
dialogs.  I'll come back to this on Monday.
Attachment #341705 - Flags: review?(joshmoz)
A new tryserver build will follow shortly.
Attachment #341705 - Attachment is obsolete: true
Attachment #342074 - Flags: review?(joshmoz)
Might this also be the cause of bug 409972 and bug 433800? 409972 has a stack, but also happens on XP. 433800 sure sounds like the same thing, though (Save As + other dialog).
(In reply to comment #14)

Bug 409972 isn't the same bug, but bug 433800 might be.

The stack for bug 409972 (attachment 294696 [details]) shows nested Gecko-modal
dialogs (nested calls to nsXULWindow::ShowModal()), but no Cocoa
app-modal dialogs (calls to -[NSApplication runModalForWindow:]).

The stack for bug 433800 (in bug 433800 comment #3) isn't worth much,
because it was made on a build (of FF3) without debug symbols.  But it
does show a call to -[NSApplication runModalForWindow:] followed by a
bunch of other junk, which *might* (if we had debug symbols) include a
call to nsXULWindow::ShowModal().
(In reply to comment #15)

> But it
> does show a call to -[NSApplication runModalForWindow:] followed by a
> bunch of other junk, which *might* (if we had debug symbols) include a
> call to nsXULWindow::ShowModal().

That's almost certainly the case, since that would be how the master password prompt is displayed.
Duplicate of this bug: 433800
Attachment #342074 - Flags: review?(joshmoz) → review+
Attachment #342074 - Flags: superreview?(roc)
Attachment #342074 - Flags: superreview?(roc) → superreview+
Landed on mozilla-central (changeset f8ad9b26a305).
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
May be fixed in beta, but still hitting this pretty frequently on mainline production build:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0

Usually encountered when saving images and using "StumbleUpon" concurrently, because SU will pre-load pages causing Cookie auth dialog to pop up at unpredictable times.
This bug's patch has (so far) only been landed on the "trunk" (aka
mozilla-central) -- what will become Firefox 3.1.

It hasn't yet been landed on the "1.9.0 branch" (in Firefox 3.0.X).
Flags: wanted1.9.0.x+
Duplicate of this bug: 477374
Duplicate of this bug: 478456
Duplicate of this bug: 488902
I reported Bug 488902 which was marked as a duplicate of this bug.  I'm running Shiretoko 3.5b4 and getting (I believe) the latest updates of that branch on a daily basis.  

This bug was marked as RESOLVED FIXED, but honestly I can't figure out which code branch, tag or trunk the version of Shiretoko I'm running is coming from, and therefore cannot check to see if the patch that supposedly fixes this bug is actually in the codebase I'm running.

The last comment is "what will become Firefox 3.1."  Well that is now 3.5 I believe, and since I'm running 3.5b4, and still experiencing this bug, either I have a new bug to report, or this bug, while fixed in one line of code, has not made it to the code I'm running.

So -- where is this fixed?  How do I tell what branch or tag or version of code from git I am running?  Update I'm running Shiretoko 3.5b4pre 20090420031111 nightly.  Still, where do I find that branch/tag in git?
Peter: As far as I can see this bug has not been fixed on the 1.9.1 branch, which you are running. Comment 18 indicates it was checked in on the trunk, but it if was fixed on 1.9.1 the "fixed1.9.1" keyword would appear in the status whiteboard. Steven - does this need need to land on the 1.9.1 branch?
Oops.  I incorrectly duped bug 488902 to this bug.  I've now duped bug 488902 to bug 476541.
> Peter: As far as I can see this bug has not been fixed on the 1.9.1
> branch, which you are running. Comment 18 indicates it was checked
> in on the trunk, but it if was fixed on 1.9.1 the "fixed1.9.1"
> keyword would appear in the status whiteboard.

Actually, this landed on the trunk before the 1.9.1 branch split off
from it -- so this fix exists on both the trunk (mozilla-central) and
the 1.9.1 branch, but not on the 1.9.0 branch.

> Steven - does this need need to land on the 1.9.1 branch?

No :-)
Thanks Steven -- Makes more sense now!  Thanks.  Will review Bug 476541 accordingly.
You need to log in before you can comment on or make changes to this bug.