207939 - Cookie confirm dialogue freezes running downloads until dismissed

Status: VERIFIED DUPLICATE of bug 74331

(Core :: Networking: Cookies, defect)

Description

[Errol Smith]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-GB; rv:1.4) Gecko/20030529
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-GB; rv:1.4) Gecko/20030529

If you start a (large) download and navigate to a site that causes a cookie
confirm box to appear, the download will freeze (stop pulling network data)
until the cookie dialogue is dismissed (the OS may buffer data in it's stack for
a while).
Once the box is dismissed the download resumes. 

Reproducible: Always

Steps to Reproduce:
1. Start a large download (several meg), preferably on a slow link (eg modem)
2. Go to a page that causes a cookie confirm dialogue to appear. eg remove one
of your favourite sites from the cookie manager and navigate it until a cookie
is changed/set
3. Leave the confirm box open and wait.
4. Watch the download window and/or your modem lights

Actual Results:  
The download freezes while the cookie confirm-box remains open. The modem may
keep flashing for a while but data flow will eventually stop (98 seems to buffer
around 60k of data before the modem lights go silent).
Dismissing the cookie box sees the download "jump" instantly about 60-80k and
then the modem will start up again and the download will continue (if it hasn't
timed out at the server end...)


Expected Results:  
Any downloads should continue regardless of what confirm boxes or dialogues are
open (obviously!).

The download site(s) had no connection to the site requesting to set a cookie.
Tested with both FTP & HTTP downloads, same result.
Also tested with both "regular" download windows and using the download manager
(same result).
This may affect loading of large images in webpages (unconfirmed).
Comment: Downloads can be lost due to server timeout if a cookie box pops up
after you've walked away from the machine (this is how I noticed this bug...).

Comment 1

[[e-mail]]

modal dialogs block necko, because necko is on the same thread as the UI I believe.

this won't be easy to fix.

it's an architectural problem afaict - our implementation of 'modal' is too
broad and covers things it really shouldn't...

(this also occurs with modal prompt dialogs in mailnews, which seriously degrade
usability if you have mailnews checking mail frequently in the background)

darin, any thoughts?

Comment 2

[Matthias Versen [:Matti]]

*** This bug has been marked as a duplicate of 74331 ***

Comment 3

[benc]

VERIFIED/dupe:

although, in the case of cookies, you could put up the dialog AFTER the file
transfer is complete... This would not prevent the larger problems w/ blocking
necko, but at least it would not jam up the immediate request.

Comment 4

[Errol Smith]

Re Comment #3,

If your download is going to take another hour to complete, then interupting a
cookie request from another window for that long would be worse than the
original problem! :-)

(we are lucky that OS TCP/IP stacks buffer data, or this would get reported
dozens of times a day and would cause serious grief. The way it is, many people
won't notice unless they do what I did and leave the browser alone with a "modal
dialogue" open..)

Comment 5

[benc]

Yeah, but that happens already anyhow.

And, to clarify a bit, TCP/IP buffers very little data. We probably force the
window size to zero.