Closed Bug 74331 Opened 24 years ago Closed 19 years ago

modal dialog in any window blocks all networking (download, browsing, mail)

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: neil, Assigned: darin.moz)

References

Details

(Keywords: perf)

I was in Chatzilla, and an alert dialog box came up in mozilla. The message screen in chatzilla does not update until I press okay on the dialog in the www browser. At the same time, the irc client timed out (The server didn't get a ping from the client because it was waiting for the dialog box) and disconnected me from the server.
Reporter what build id are you using?
I get a new nightly, nightly. So it was either one of the builds from the day I filed the bug, or the day before. I just tried it with build 2001040108 and it happened again. Open a chat window, then in a browser window try to connect to a site which doesn't exist. A dialog will come up and the chat window will stop updating.
This is a real bug, but there is nothing I can do about it in chatzilla. chatzilla relies on callbacks from necko to tell it that information is available from the server (like a ping request.) All of those events (and more) are blocked by the modal dialog box. Unblocking them wholesale would surely break something else. I don't know what to do about it. cc'ing danm in case he has any bright ideas.
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Sending to Networking. This messes up the browser, too: if an alert is displayed in one window, clicking on links in another window doesn't work. Once I dismiss the alert in the first window, the throbber starts animating and the link loads. (Fwiw, the alert in the first window doesn't block me from navigating session history in the second window.) I found several bugs that look related, but they're all linux-only: bug 61590 Modal "OK" warning windows eat CPU - see trace bug 56978 alert dialog consumes 100% cpu if network is down bug 65521 modal dialogs should only freeze parent window (not all windows)
Assignee: rginda → neeti
Component: chatzilla → Networking
QA Contact: mozilla → tever
Summary: Modal dialog boxes stop IRC from doing anything → modal alert dialog in any window blocks necko for all windows
Target Milestone: --- → mozilla1.0
qa to me +cc mpt changed subject to clarify what is needed. (I've read most of the related error bugs, and this one is closest to the RFE I wanted to file...) I think what is needed is an error mode (that should be prefs pickable), that creates a error list window. Errors would get sent to it (the way vacation messages pile up in AIM...), but would be non-blocking, not waiting for user confirmation. For my purposes, this would ideally over-ride all the other types of error behavior we have discussed in various bugs (send to a page, send to a dialog, display broken icon for missing inline graphic, etc). Power users and network analysts would love this feature because it gives them total visibility to what network problems occur. It would also be great for ibench and browser buster testers, because intermittent errors would not lock up the test until a human clears the error dialog. My thinking here is that our current error handling reflects a misunderstanding about errors needing blocking network access. Most network errors are transient, and they do not actually block further network access. They do however, block the user experience, because you assume that the browser was pulling something that a user wanted to see. There are some potential problems (like infinite errors logged when a router goes down w/ a continuous test), but I think these could be worked out...
QA Contact: tever → benc
Summary: modal alert dialog in any window blocks necko for all windows → [RFE] Need network errors to go to non-blocking list or display
Speaking of non blocking. my crummy twm blocks (stalls app -- esp unattended choffman's browser buster which always has one url w/ no dns) whenever a window is created (waiting for the user to place it). Either i need to be able to have this appear into the sidebar, or I need it to get stored for loading via menu/url. javascript: brings up the javascript error console, perhaps network: [or about:network] could bring up a network error console. An error indicator in the statusbar would be nice (just like we have a proposal for an html quality indicator). [online indicator] [network status] [security status] [html quality]
Benc (or timeless), please file a new bug for "[RFE] Need network errors to go to non-blocking list or display". This is a bug, so it shouldn't be turned into an RFE to create a mode where the original bug wouldn't happen. This bug also covers alerts as well as networking errors, and alerts can't just be tossed into a console to be viewed later, at least not by default.
Summary: [RFE] Need network errors to go to non-blocking list or display → modal alert dialog in any window blocks necko for all windows
Jeese: I don't think that changing the underlying necko behavior without modifying the modal alerts is really a solution. Then you would see the irritating behavior I get in Communicator for Solaris, where about 25 non-blocking modal dialogs stack up. You end up hitting okay for about 15 minutes, and sometimes the window manager barfs, so you lose everything. Anyhow, I created bug 80293: [RFE] Need network errors to go to non-blocking list or display, for discussion of what I suggested above.
I think alerts should be queued by window. Only one should appear for any window at one time, but that should not prevent other alerts from being opened for other windows at the same time.
so it's ok for a window to queue 1000 alerts?
No, but that's not relevant to this bug. Mozilla putting up 1000 alerts all at once wouldn't be any better than Mozilla putting up 1000 alerts one after the other.
For more discussion of the DoS attack where a page puts up 1000 alerts, see bug 59314, "Alerts should be content-modal, not window-modal".
*** Bug 95899 has been marked as a duplicate of this bug. ***
*** Bug 99968 has been marked as a duplicate of this bug. ***
*** Bug 103169 has been marked as a duplicate of this bug. ***
*** Bug 104202 has been marked as a duplicate of this bug. ***
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 141870 has been marked as a duplicate of this bug. ***
WFM for javascript alert(), but I still can't click on links in any window while the Windows file picker is active (for Save As).
Target Milestone: mozilla1.0.1 → Future
Keywords: mozilla1.1
OS: Windows 2000 → All
Hardware: PC → All
Keywords: perf
Blocks: 95899
moving neeti's futured bugs for triaging.
Assignee: neeti → new-network-bugs
*** Bug 95899 has been marked as a duplicate of this bug. ***
*** Bug 117645 has been marked as a duplicate of this bug. ***
*** Bug 132999 has been marked as a duplicate of this bug. ***
I would suggest to extend the summary. A lot of dupes (like the last 3) have only "download" and "dialog" as catchwords. Not all people search in such a case for "modal dialog" and "necko". Like me. This bug could lead to dataloss due to timeouts of the halted downloads. That is not only normal severity and not only a performance issue. Keyword mozilla1.1 is obsolete too.
No longer blocks: 95899
Keywords: mozilla1.1
Summary: modal alert dialog in any window blocks necko for all windows → modal alert dialog in any window blocks necko for all windows (dialog box blocks download)
ostgote@gmx.net: Please suggest a new summary! having summaries that are found in searches is very important to me.
*** Bug 203585 has been marked as a duplicate of this bug. ***
*** Bug 207119 has been marked as a duplicate of this bug. ***
*** Bug 207939 has been marked as a duplicate of this bug. ***
*** Bug 209616 has been marked as a duplicate of this bug. ***
-> defaults, clean-report This needs engineering attention.
Assignee: new-network-bugs → darin
Keywords: clean-report
Summary: modal alert dialog in any window blocks necko for all windows (dialog box blocks download) → modal alert dialog in any window blocks all networking (download, browsing, mail)
*** Bug 210980 has been marked as a duplicate of this bug. ***
nominating. this seems to affect every network-dependent component.
Keywords: nsbeta1
yes it does, a single WWW page not loading properly does crash all your chatzilla irc connections, if you don´t hit Ok quick enough this bug is far over 2 years old, only one of many
I have another bug that I think is caused by this: While Save Image As dialog is open you can't open any mail message. When you close that dialog mail messages are open.
*** Bug 196015 has been marked as a duplicate of this bug. ***
There is a $500 bounty for bug 28586 but I believe that this bug is (or should?) be involved: http://www.markshuttleworth.com/bounty.html "Error dialogs slow down the browsing process, especially when one is using tabbed browsing and opening up multiple links in background tabs to be read later." Given that this bug stops all networking (like loading of pages in other tabs/windows while an error dialog is open..) it seem more than relevant.
Blocks: errorpages
NOTE: Fixing 28586 (which is not so much a meta bug as a messy bug), would solve the original problem, which is that network error dialog boxes modally block I/O. What I did NOT expect, but many people have wisely duped into this bug, is ALL dialogs (cookies, save as, etc...) seem to block network I/O. I originally thought this "bug" could be solved by implementing 28586, but the problem is broader (and more severe) than I originally thought. The relevant dupes are: 132999, 196015, 207119, 207939, 209616, 210980.
Summary: modal alert dialog in any window blocks all networking (download, browsing, mail) → modal dialog in any window blocks all networking (download, browsing, mail)
Regarding comment #38: You could also add bug 137909 (a dupe of 132999) as well as: bug 201374 "Browser functionality diminished when any "Save" dialog open" bug 150006 "URL non responsive when a mail dialog is open (i.e Save As dialog)" (both waiting to be duped to something - sorry, no permissions for me). Also I think this bug might be the underlying cause of the known issue regarding "Dialog Boxes and Windows" (http://www.mozilla.org/releases/mozilla1.6/known-issues.html#focus) "If Mozilla is locked up but doesn't seem to have crashed, make sure there are no dialog boxes still open. Close each window on your desktop one at a time and if you uncover a dialog window, dismiss it. If you have multiple desktops, repeat these steps for each desktop."
(In reply to comment #39) > bug 201374 "Browser functionality diminished when any "Save" dialog open" > bug 150006 "URL non responsive when a mail dialog is open (i.e Save As dialog)" I can provide 3 more potentially dupe candidates: bug 184593 "modal dialogs block all browser windows" bug 207608 "compact all local folders?" blocks loading pages i..." bug 223491 "Autocomplete of email addresses in compose fails if a fil..."
*** Bug 236789 has been marked as a duplicate of this bug. ***
*** Bug 171947 has been marked as a duplicate of this bug. ***
*** Bug 184593 has been marked as a duplicate of this bug. ***
*** Bug 207608 has been marked as a duplicate of this bug. ***
Similar bug in MailNews: bug 195596 Mail retrieval stops after error messagebox displaying server error
*** Bug 163000 has been marked as a duplicate of this bug. ***
*** Bug 220143 has been marked as a duplicate of this bug. ***
*** Bug 236775 has been marked as a duplicate of this bug. ***
*** Bug 248117 has been marked as a duplicate of this bug. ***
What is the status of this bug? I just upgraded to Mozilla 1.7 and found that not all modal dialogs block all Mozilla windows. (I had a timeout dialog on one of my windows, which I only noticed when I switched back to it. Previously, this dialog would block all other windows.) A simple test shows that not all problems are solved though: 1) press ctrl+S in one window/tab 2) happely browse in another window/tab 3) try to retrieve new mail 2 works, 3 does not.
(In reply to comment #50) > 1) press ctrl+S in one window/tab > 2) happely browse in another window/tab > 3) try to retrieve new mail > > 2 works, 3 does not. With Mozilla 1.7 or current trunk build on WinNT4 neither 2 nor 3 works. Nothing has changed AFAIK. The modal "save as" dialog doesn't allow you to switch tabs! See Bug 123913 and its dupes like bug 240824 or bug 248872. In step 2) you can switch to another - already open - window, but in that window you can't browse anything until the dialog is closed.
(In reply to comment #51) > With Mozilla 1.7 or current trunk build on WinNT4 neither 2 nor 3 works. > Nothing has changed AFAIK. I am using 1.7 for Linux, and I just double checked that the statement I made in commet #50 still holds. Interesting that it is still broken in Windows.
*** Bug 251624 has been marked as a duplicate of this bug. ***
It seems strange that there has been no progress on this bug after more than three years. It has 23 officially recognised duplicates and several more possible ones, more than 50 people on its CC list, and 19 votes - and would probably get more votes if the duplicate reporters and others on the CC list remembered to vote for it. There is even a possible $500 bounty for fixing it (see comment #37). But there has been no progress at all. Is there a good reason for that?
> Is there a good reason for that? everyone has their priorities... patches welcome. (also, next time it would be better to post a comment in one of the newsgroups or send me direct mail. bugzilla comments that don't help with the solution of this bug are just noise that makes it harder to find the comments that do matter. if you want this bug fixed, then minimize the spam in the bug itself, thx!)
Keywords: helpwanted
*** Bug 262248 has been marked as a duplicate of this bug. ***
Sorry for making a dupe. my bad. I did search but it returned nothing. But 3 years of a bug? I suggest moving it to a higher severity...
*** Bug 191243 has been marked as a duplicate of this bug. ***
Of course, you lot don't need telling that this bug is still in Mozilla, but here's another example for ya anyway. At our site our intranet server is set to be the home page and Mozilla is often used as browser. We've been having stability problems with our intranet server lately, and the result of this and this bug is that because users have a dialogue box showing an unavailable/unreachable message they cannot access their (Mozilla) mail and furthermore all of "The Internet" appears unreachable. This has resulted in lots of phone calls where we end up telling users to simply get rid of the dialogue box.
If a complete fix is too difficult because of how it might affect other modules, how about a temporary solution of bringing all modal dialogs to the top of the desktop whenever anything attempts blocked I/O? This would avoid the problem that these dialog boxes tend to get hidden under many windows and so hard to find.
Peter, that is why this bug blocks bug 28586 (actually, it should be the opposite).
(In reply to comment #51) > (In reply to comment #50) > > 1) press ctrl+S in one window/tab > > 2) happely browse in another window/tab > > 3) try to retrieve new mail > > > > 2 works, 3 does not. > > With Mozilla 1.7 or current trunk build on WinNT4 neither 2 nor 3 works. > The modal "save as" dialog doesn't allow you to switch tabs! [...] > In step 2) you can switch to another - > already open - window, but in that window you can't browse anything until the > dialog is closed. With Mozilla 1.8a5 on WinNT4 (and proxy) I see the following situation (behavior changed): Have two windows with 2 tabs and open in window 1 a save as dialog (ctrl+s). Results: In window 1 you can't do anything. No new tab/window, no tab switch, no surfing, no typing etc. Already running downloads from window 1 keep loading and finish but the completion alert is not shown until the modal dialog is closed. You can switch to the other window 2. In that window you can load new pages, open new tabs/windows, switch tabs BUT you cannot use the url bar to open pages (enter does nothing, autocomplete is off), you can only use bookmarks/history/reload. New downloads from window 2 work.
*** Bug 271425 has been marked as a duplicate of this bug. ***
*** Bug 271759 has been marked as a duplicate of this bug. ***
*** Bug 273479 has been marked as a duplicate of this bug. ***
*** Bug 168735 has been marked as a duplicate of this bug. ***
the master password dialog seems to cause the same behaviour (thus the duping of bug 168735). i am assuming that this is the same problem; if it's not, please undupe (and check out) that bug.
*** Bug 281077 has been marked as a duplicate of this bug. ***
*** Bug 284919 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > I was in Chatzilla, and an alert dialog box came up in mozilla. The message > screen in chatzilla does not update until I press okay on the dialog in the www > browser. > At the same time, the irc client timed out (The server didn't get a ping from > the client because it was waiting for the dialog box) and disconnected me from > the server.
We have had a very obscure bug in Forecastfox since last fall, and we have finally isolated where it occurs and what exception is thrown. It may be caused by this bug, but I am not sure. If a modal dialog pops up on startup, which in our case is usually caused by SessionSaver saving a page that requires login, Forecastfox's initial calls to nsIDOMParser and XMLHttpRequest fail. They both fail with the same exception, which shows up in nsIDOMWindowInternal: An error occured while trying to load the profiles module. Exception details: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowInternal.focus]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://global/content/bindings/tabbrowser.xml :: setFocus :: line 638" data: no] The trace on the JavaScript exception goes right from that exception to the send method on the XMLHttpRequest, and the parseFromStream method of the nsIDOMParser. I'm working on getting a debug build of Firefox up and running so that I can trace the c++, but I haven't been able to do that yet. Could this be related? If not, can anyone point me in the correct direction?
Bug 299464 is another examples of this - if you leave the Save As Dialog up for a while, depending on the server, existing downloads (which have frozen due to this bug) can timeout and abort. This is particularly a problem with large files in a list, after a couple of downloads have started, the Save As dialogs stop coming up, and are just queued internally, they pop-up after a while, seemingly at random, so if you are not at your machine, the earlier downloads can timeout.
*** Bug 299464 has been marked as a duplicate of this bug. ***
*** Bug 300803 has been marked as a duplicate of this bug. ***
Where are the modal-dialog blocking boxes spawned from? Do they come from each individual window's process, or do they come from an error handler that's prior to instead of concurrent with the other windows? If the dialog boxes were coming from windows running concurrently with other windows, the other windows shouldn't be blocked, right?
All Windows are the same single process and the Dialog is coming from teh UI Thread.
That shows how little I know about it. But if all Mozilla windows are the same thread, then Mozilla handles the concurrency of its own windws and is failing to do it in the case of certain dialog boxes. Does this have something to do with Mozilla polling those dialogs in a tight loop instead of handling them on an on-interrupt event basis?
>All Windows are the same single process and the Dialog is coming from teh UI Thread. That explains a lot - I've only EVER seen a single process entry for Firefox in the TaskManager... Now I know why the whole thing blocks and freezes so much. I assume that there is some threading within the process, but it is either done badly or it is not effective. The poor threading means that anytime some website behaves badly, or stalls on loading, all the Firefox tabs and windows freeze or become jerky. Stop using Modal windows without need - take a look at NetScape 4.76 if you want to see how to do the SaveAs dialog (and others) properly - it comes up as a plain child window. You can access the original window - you can even click away from the page, and the SaveAs is still waiting there, properly z-stacked, not 'always on top' and NOT BLOCKING ANYTHING. Stop copying Internet Explorer, copy some decent coding !!! The General rule should be that anything independent should be INDEPENDENT - i.e. in a separate thread. 1 All tabs/windows should have a separate thread - to stop a large page/poorly coded site from affecting the others. 2 The download manager should be a separate thread - so that downloads are not 'paused' by other windows (some sites will dump a download if it pauses too long) 3 The SaveAs dialog should be a separate thread - and certainly not modal - there is no reason to be modal - if I want to grab part of the URL to use for the filename/folder, I can't do it without closing the SaveAs - and while the SaveAs is open, the downloads freeze, see problem above. 4 The find should be a separate thread - when I'm viewing a 25Meg log file, the find locks everything else up. 5 Probably a lot more that others can suggest. This was obviously all down to a very bad design decision (or lack of thought) at the very early stages. Whether it will now be possible to thread the program properly is down to the programmers. Will anyone even say that they are going to look at it. Otherwise, as other features get added, the program just has more and more chance of locking up :( It's starting to become unusable for me, I switched from NetScape 4.76 to FF, and that old NS was FAR more responsive and better threaded and written. PLEASE address this threading issue, I am starting to use NS again for sites that I know it works with, what's the point in having tabs when they block each other !
I agree with almost everything Mr Brooks says, but I have to somewhat disagree with the "not always-on-top" remark. Though I agree that always-on-top has its own problems (see note below), if you are waiting on the user to ack a certificate, for example, to display a page (or read email), the last thing you want to do is have the dialog windows accidentally go behind the main window -- especially if they, as "children" windows, don't show up in the OS's bottom bar as application, as the user will never know there's anything in need of ack'ing until he moves the top window around (yes, that is a scenario that can actually happen even now!). Dialogs ought to be more "anoying" than regular windows. Non-modal, yes I agree with that -- copy and paste are important, and moving from one tab to the other essential (a tab might even have the username/password you need to type for auth in another tab). If I had my way, these dialogs would be like a singular, regular (tabbed) child window, and there would be a waving flag on the main window indicating whenever there are dialogs awaiting for user interaction, and take them there if clicked... But that's just me. Zorzella
If you start a download and leave your keyboard for a while, and your mail program is set to check the mail every 15 or 60 minutes for example, the Security Warning dialog will stop your download. Mozilla's own servers drop downloads for this reason. Servers can't afford to wait forever to send data. One must change the mail settings or stay at the keyboard to make sure a download is truly completed. And that's one of the reasons why dialog boxes shouldn't block activity in other windows.
I just lost a webmail email that I spent more than half an hour writing, because of the security warning dialog box Mozilla displays each time it fetches pop mail from my server. The problem is the window switching that rips the focus away from what a person is doing in other mozilla windows. This shouldn't happen.
Yes, the focus switching is also very annoying on the Download Manager. If you have it set to show after 5 or 10 secs (so that it doesn't show up for each piddly little image) then you suddenly loose focus from the main window - sometimes is flicks the focus several times in succession - please get your coding sorted out, or people are going to stop using it! "Opened: 2001-04-01" This bug has been around for over 4 years, you are showing complete contempt for your user base by not addressing this issue.
nigel_brooks@compuserve.com: you're showing complete contempt for our developer and bugzilla userbase by not being polite and following the etiquette rules. as penance we invite you to fix this bug.
Assignee: darin → nigel_brooks
timeless@bemail.org - stop being such a j$&k - this bug has been unresolved for over 4 years, if this bug reporting system is anything more than some sort of stupid chat room it should have been sorted by now. I don't know who it was assigned to before, so I'm assigning it to you. Can someone please take control of this, and get it fixed.
Assignee: nigel_brooks → darin
On my system, two bugs interacted to cause my webmail-sending problem yesterday. One was the "domain name mismatch" security warning resulting from trying to use security on POP mail, and the other was this one, which is that some dialog boxes stop other mozilla traffic. The question of what's done with the focus might be yet another bug. Would it be better to have a dialog box signal its presence by blinking the taskbar entry instead of changing the focus? The most important issue of these is that a dialog in one window not stop traffic in other windows. It can't be assumed that a user is always at the keyboard responding to dialog boxes.
*** Bug 161188 has been marked as a duplicate of this bug. ***
*** Bug 302799 has been marked as a duplicate of this bug. ***
Now I know why many of my downloads in firefox "randomly" stopped. Why hasn't this been fixed by now? I think everyone agrees that a modal window should *never* stop any network transfer - so this is a real issue here!
Another way to reproduce this: Open two Browser Windows. Open a page in one window. Open up the save dialog in that window. Go to the other window and try to open an url there. The page will only show up, after you close the save dialog in the other window. All other modal dialogs (File open, print setup, options) seem not to have any effect. So what's so special about the save dialog that it needs to block other dialogs and network transfer that way?
*** Bug 224235 has been marked as a duplicate of this bug. ***
(In reply to comment #90) > Another way to reproduce this: > Open two Browser Windows. Open a page in one window. Open up the save dialog in > that window. Go to the other window and try to open an url there. The page will > only show up, after you close the save dialog in the other window. WFM with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050829 Firefox/1.0+
I see the exact same behaviour as described in comment #90 using Windows XP Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 In reply to comment #92 : maybe this test case is Windows specific, or are you implying that this bug is solved in the latest nightly build?
(In reply to comment #93) > In reply to comment #92 : maybe this test case is Windows specific, or are you > implying that this bug is solved in the latest nightly build? To see if this testcase is windows specific you have to use a nightly build instead of an aviary release build!
Please specify which build you tested with, and I'll gladly test it under Windows. ftp://ftp.mozilla.org/Public/mozilla.org/firefox/nightly/ gives me 2 choices for today: 2005-08-29-06-aviary1.0.1 2005-08-29-06-mozilla1.8
The bug seems to have been fixed (worked around I suppose), as the page now loads, when another window displays a saved-as dialog, but clicking on tabs doesn't work and the status bar never displays "done". Thats using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050828 Firefox/1.6a1.
I tested on Windows 2003 with nightly builds of 29/08/2005. Bug still present in Firefox 1.0.6 from the 2005-08-29-06-aviary1.0.1 directory Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7.10) Gecko/20050829 Firefox/1.0.6 Bug not present in Deer Park Alpha 2 from the 2005-08-29-06-mozilla1.8 directory Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8b4) Gecko/20050829 Firefox/1.0+ Bug not present in Deer Park Alpha 2 from the 2005-08-29-07-trunk directory Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a1) Gecko/20050829 Firefox/1.6a1 So my conclusion is that for the fix you need a high enough rv number (at least 1.8?), regardless of the Gecko version.
(In reply to comment #97) > So my conclusion is that for the fix you need a high enough rv number (at least > 1.8?), regardless of the Gecko version. Upcoming Aviary builds only contain security related fixes and won't be fixed on that issue. You need at least a mozilla1.8 nightly build. I repeated the tests with different modal dialogs with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+ and also can't see the issue on Windows. Linux and Windows builds seems to work now like some others told within the last comments. Anyone who could test it on Mac OS? If it doesn't occur on this platform we could mark this bug as WFM?
I still experience a complete lockup of all windows when the "Save file as..." dialog is open, using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de; rv:1.8b4) Gecko/20050815 Firefox/1.0+ on Mac OS X 10.3.9. It also occurs using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050829 Firefox/1.6a1 So I have to say its still a problem on Mac OS X.
On recent Seamonkey trunk, this is what happens now. I got a modal dialog about a server error from mailnews that was up most of the day. ChatZilla was running just fine. However, when I got home and closed the dialog, the socket ChatZilla was using was immediately closed.
*** Bug 296943 has been marked as a duplicate of this bug. ***
Using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050910 SeaMonkey/1.0a, the "save-as" dialog doesn't lock up the download manager, but the certificate warning box (email) does.
Using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051021 SeaMonkey/1.1a, the Save-as dialog box seems to stop another download and presumably other traffic. So the multitasking isn't perfected yet.
Keywords: clean-report
*** Bug 320602 has been marked as a duplicate of this bug. ***
*** Bug 321307 has been marked as a duplicate of this bug. ***
Bug is still present on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Although things have gotten better: When a modal dialog is opened, all windows already open keep functioning as they should. Then again, newly opened windows (either by launching firefox.exe again, or choosing file->new window) are not functioning at all. The buttons and visual stuff does work, but it doesn't load a webpage until the modal dialog is closed.
*** Bug 327862 has been marked as a duplicate of this bug. ***
*** Bug 327797 has been marked as a duplicate of this bug. ***
*** Bug 322091 has been marked as a duplicate of this bug. ***
As per Bug 322091, holding on a scrollbar can also trigger this behaviour.
*** Bug 334467 has been marked as a duplicate of this bug. ***
*** Bug 334580 has been marked as a duplicate of this bug. ***
*** Bug 334525 has been marked as a duplicate of this bug. ***
*** Bug 335915 has been marked as a duplicate of this bug. ***
This was fixed by the thread manager patch in bug 326273.
Status: NEW → RESOLVED
Closed: 19 years ago
Depends on: nsIThreadManager
Resolution: --- → FIXED
I just experienced this bug restoring a session using Session Manager 0.5.3.2 in Firefox 2.0.0.2 on K/Ubuntu 6.10. Are SSL dialogs different?
(In reply to comment #116) > in Firefox 2.0.0.2 on K/Ubuntu 6.10. Are SSL dialogs different? Bug 326273 is 1.9 trunk only: not 1.8.1 branch...
Keywords: helpwanted
Target Milestone: Future → ---
See Also: → https://launchpad.net/bugs/14576
You need to log in before you can comment on or make changes to this bug.