Closed Bug 74331 Opened 23 years ago Closed 18 years ago

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

Categories

(Core :: Networking, defect)

defect
Not set
normal

Tracking

()

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: 18 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 → ---
You need to log in before you can comment on or make changes to this bug.