Closed Bug 436473 Opened 12 years ago Closed 12 years ago
firefox hangs if cookie ask permission to set whilst save target as dialog is open (image)
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?
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.)
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+
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
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.
Here's a tryserver build made with my patch (attachment 341705 [details] [diff] [review]): https://build.mozilla.org/tryserver-builds/2008-10-03_16:firstname.lastname@example.orgemail@example.com
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.
A new tryserver build will follow shortly.
Here's a tryserver build made with my rev1 patch: https://build.mozilla.org/tryserver-builds/2008-10-07_08:firstname.lastname@example.orgemail@example.com
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.
Attachment #342074 - Flags: superreview?(roc)
Attachment #342074 - Flags: superreview?(roc) → superreview+
Landed on mozilla-central (changeset f8ad9b26a305).
Status: NEW → RESOLVED
Closed: 12 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).
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?
> 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.