invalid certificate dialog blocks all future pages from loading

[Adam Lydick]

When the "invalid certificate" dialog is shown, new pages that you open never
actually load.

Repro:

NOTE: Firefox is configured to spawn new windows when an external app opens a URL.

* Visit a page with a bogus cert: https://launchpad.ubuntu.com/people/lydickaw
(I clicked the link in another app -- Evolution)
* Ignore the certificate dialog (I accidentally hid it behind some other windows
when I hit this)
* Try to open a new page: http://www.gnome.org/projects/beagle (also from
another app -- Evolution)
* Both windows are blank and the throbber spins forever until you close the dialog.

Expected behavior: Only block the loading of the page with the bogus cert.

[Verbal-myrealbox (verbal-myrealbox)]

Reporter what build id are you using?

[Neil-eightlines (neil-eightlines)]

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.

[Rginda (rginda)]

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.

[Verbal-myrealbox (verbal-myrealbox)]

Marking NEW.

[Jruderman (jruderman)]

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)

[Benc-meer (benc-meer)]

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

[Timeless-bemail (timeless-bemail)]

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]

[Jruderman (jruderman)]

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.

[Benc-meer (benc-meer)]

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.

[Matthew Paul Thomas (mpt)]

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.

[Timeless-bemail (timeless-bemail)]

so it's ok for a window to queue 1000 alerts?

[Matthew Paul Thomas (mpt)]

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.

[Jruderman (jruderman)]

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

[David-illsley (david-illsley)]

*** Bug 95899 has been marked as a duplicate of this bug. ***

[Caillon (caillon)]

*** Bug 99968 has been marked as a duplicate of this bug. ***

[Matti-mversen (matti-mversen)]

*** Bug 103169 has been marked as a duplicate of this bug. ***

[Matti-mversen (matti-mversen)]

*** Bug 104202 has been marked as a duplicate of this bug. ***

[Asa (asa)]

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)

[Pab-blinkenlights (pab-blinkenlights)]

*** Bug 141870 has been marked as a duplicate of this bug. ***

[Jruderman (jruderman)]

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

[Dougt (dougt)]

moving neeti's futured bugs for triaging.

[Dougt (dougt)]

*** Bug 95899 has been marked as a duplicate of this bug. ***

[Bzbarsky (bzbarsky)]

*** Bug 117645 has been marked as a duplicate of this bug. ***

[Bzbarsky (bzbarsky)]

*** Bug 132999 has been marked as a duplicate of this bug. ***

[Ostgote (ostgote)]

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.

[Benc-meer (benc-meer)]

<email address hidden>: Please suggest a new summary! having summaries that are found
in searches is very important to me.

[Samuel-sieb (samuel-sieb)]

*** Bug 203585 has been marked as a duplicate of this bug. ***

[Matti-mversen (matti-mversen)]

*** Bug 207119 has been marked as a duplicate of this bug. ***

[Matti-mversen (matti-mversen)]

*** Bug 207939 has been marked as a duplicate of this bug. ***

[Bzbarsky (bzbarsky)]

*** Bug 209616 has been marked as a duplicate of this bug. ***

[Benc-meer (benc-meer)]

-> defaults, clean-report
This needs engineering attention.

[Matti-mversen (matti-mversen)]

*** Bug 210980 has been marked as a duplicate of this bug. ***

[Benc-meer (benc-meer)]

nominating. this seems to affect every network-dependent component.

[Koka (koka)]

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

[Jure Repinc (jlp)]

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.

[Christian Biesinger (cbiesinger)]

*** Bug 196015 has been marked as a duplicate of this bug. ***

[Errol (errol)]

 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.

[Benc-meer (benc-meer)]

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.

[Errol (errol)]

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

[Ostgote (ostgote)]

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

[JohnT (jrt-worldlinc)]

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.

[Ostgote (ostgote)]

*** Bug 161188 has been marked as a duplicate of this bug. ***

[Ostgote (ostgote)]

related bugs: bug 150006, bug 158030, bug 223491, bug 289996, Bug 144601/Bug 251396

[Adam Guthrie (ispiked)]

*** Bug 302799 has been marked as a duplicate of this bug. ***

[Jabernet (jabernet)]

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!

[Jabernet (jabernet)]

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?

[Arthur (moz-liebesgedichte)]

*** Bug 224235 has been marked as a duplicate of this bug. ***

[Hskupin (hskupin)]

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

[Richard-vdberg (richard-vdberg)]

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?

[Hskupin (hskupin)]

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

[Richard-vdberg (richard-vdberg)]

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

[Jabernet (jabernet)]

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.

[Richard-vdberg (richard-vdberg)]

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.

[Hskupin (hskupin)]

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

[Mmx-bugzilla (mmx-bugzilla)]

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.

[Samuel-sieb (samuel-sieb)]

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.

[Matthew Paul Thomas (mpt)]

https://bugzilla.mozilla.org/show_bug.cgi?id=74331

[Adam Guthrie (ispiked)]

*** Bug 296943 has been marked as a duplicate of this bug. ***

[JohnT (jrt-worldlinc)]

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.

[Ian Jackson (ijackson)]

*** Bug 22300 has been marked as a duplicate of this bug. ***

[JohnT (jrt-worldlinc)]

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.

[Matti-mversen (matti-mversen)]

*** Bug 320602 has been marked as a duplicate of this bug. ***

[Adam Guthrie (ispiked)]

*** Bug 321307 has been marked as a duplicate of this bug. ***

[Forceflow (baertman)]

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.

[Matti-mversen (matti-mversen)]

*** Bug 327862 has been marked as a duplicate of this bug. ***

[Matti-mversen (matti-mversen)]

*** Bug 327797 has been marked as a duplicate of this bug. ***

[Robin Monks (mozillaman)]

*** Bug 322091 has been marked as a duplicate of this bug. ***

[Robin Monks (mozillaman)]

As per Bug 322091, holding on a scrollbar can also trigger this behaviour.

[Dtownsend (dtownsend)]

*** Bug 334467 has been marked as a duplicate of this bug. ***

[Philringnalda (philringnalda)]

*** Bug 334580 has been marked as a duplicate of this bug. ***

[Philringnalda (philringnalda)]

*** Bug 334525 has been marked as a duplicate of this bug. ***

[Henrik Nilsen Omma (henrik)]

Confirmed on latest dapper with Firefox 1.5.0.2.

[Philringnalda (philringnalda)]

*** Bug 335915 has been marked as a duplicate of this bug. ***

[Darin-moz (darin-moz)]

This was fixed by the thread manager patch in bug 326273.

[Alexander Sack (asac)]

someone can confirm that this issue still exist in latest firefox (e.g. in feisty or edgy) ?

[Tmptgr (tmptgr)]

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?

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

This seems to be fixed in 2.0.0.X, feel free to reopen if you can reproduce this with 2.0.0.6.

[Sgautherie-bz (sgautherie-bz)]

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

[Matti-mversen (matti-mversen)]

*** Bug 468312 has been marked as a duplicate of this bug. ***

[Wbzsinj-bugs (wbzsinj-bugs)]

*** Bug 309349 has been marked as a duplicate of this bug. ***