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...).
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?
Assignee: general → darin
Status: UNCONFIRMED → NEW
Component: Browser-General → Cookies
Ever confirmed: true
QA Contact: general → cookieqa
*** This bug has been marked as a duplicate of 74331 ***
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → VERIFIED
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..)
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.
You need to log in before you can comment on or make changes to this bug.