dave street Reporter
	Description • 16 years ago

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

	timeless
	Comment 1 • 16 years ago

can you use sampler.app (from activitymonitor.app) to get a sample and attach the *text* version?

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 2 • 16 years ago

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.

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 3 • 16 years ago

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.)

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 4 • 16 years ago

I'm marking this qawanted to request tests on other platforms.

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 7 • 16 years ago

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.

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 8 • 16 years ago

Even if variants happen on other platforms, this specific bug is a Cocoa widgets bug.

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 9 • 16 years ago

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.

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 10 • 16 years ago

Here's a tryserver build made with my patch (attachment 341705 [details] [diff] [review]):

https://build.mozilla.org/tryserver-builds/2008-10-03_16:46-smichaud@pobox.com-bugzilla436473/smichaud@pobox.com-bugzilla436473-firefox-try-mac.dmg

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 11 • 16 years ago

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.

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 12 • 16 years ago

A new tryserver build will follow shortly.

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 13 • 16 years ago

Here's a tryserver build made with my rev1 patch:

https://build.mozilla.org/tryserver-builds/2008-10-07_08:20-smichaud@pobox.com-bugzilla436473-rev1/smichaud@pobox.com-bugzilla436473-rev1-firefox-try-mac.dmg

	Justin Dolske [:Dolske]
	Comment 14 • 16 years ago

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).

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 15 • 16 years ago

(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().

	Justin Dolske [:Dolske]
	Comment 16 • 16 years ago

(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.

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 18 • 16 years ago

Landed on mozilla-central (changeset f8ad9b26a305).

	Christopher Neill
	Comment 19 • 16 years ago

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.

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 20 • 16 years ago

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).

	Peter Beckman
	Comment 24 • 15 years ago

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?

	Marcia Knous [:marcia]
	Comment 25 • 15 years ago

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?

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 26 • 15 years ago

Oops.  I incorrectly duped bug 488902 to this bug.  I've now duped bug 488902 to bug 476541.

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 27 • 15 years ago

> 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 :-)

	Peter Beckman
	Comment 28 • 15 years ago

Thanks Steven -- Makes more sense now!  Thanks.  Will review Bug 476541 accordingly.