401256 - Cookie generation nearly continuous if Prefs set to "Ask".

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: General, defect)

Description

[Frobozz]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.9a9pre) Gecko/2007102602 Camino/2.0a1pre (like Firefox/3.0a9pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.9a9pre) Gecko/2007102602 Camino/2.0a1pre (like Firefox/3.0a9pre)

Annoying web-page generates so many cookies and so fast that, despite checking the first one "Deny" and "remember this", many many more appear (a malicious web site) and I must use "Force Quit"

1. remember this decision does not cause next immediate cookie to be generated
2. cookie generation is so fast and many many cookie-decision pop-ups occur before user can react

FWIW, using Minefield, I see a single window, which waits for me to check "Deny" and remember decision ... yet STILL another similar window appears. I got to about thirty before killing Minefield also ... it was just that I could handle one at a time and not have dozens of cookie windows appear as they do in Camino

Reproducible: Always

Steps to Reproduce:
1.Set Cookie Prefs to ASK each time
2.go to obnoxious web URL above (be ready to Kill Camino though)
3.Deny and "remember decision"  if you are fast enough
4. Observe more cookie request appearing 
Actual Results:  
see jpeg of screenshot
"Force Quit" Camino

Expected Results:  
decision to not allow cookies from wi-fiplanet.com should have been accepted and subsequent cookies rejected

browser should detect a site trying to throw cookies so fast in a manner which seems to suggest the site is punishing the browser for denying cookies to begin with.


Issued forth a single Cookie handling decision point for user

rejected ALL subsequent cookies from site if user requested that option

* optionally for the pugilistic browser user upset with being hammered, suggest a coffee-spilling bot to be sent to offending web-site's programmer at the appropriate time.

Comment 1

[Frobozz]

Attachment: Screenshot-Camino

Comment 2

[Frobozz]

Attachment: Minefield_result

Comment 3

[Frobozz]

Attachment: about config

Comment 4

[Frobozz]

Comment on attachment 286303 [details]
Screenshot-Camino

sorry about that ... re-added this jpeg

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I see this, only on the trunk, but I don't have to force quit at all.  I can just wait until wi-fiplanet.com is done generating its ca. 10 cookie requests (plus the two from its ad sites), and then click/Esc through the accumulated ones.

On branch, there's one cookie sheet per domain.

Stuart, have we changed anything about our sheet-handling on trunk recently that would make cookie requests stop queuing up and instead go modal on each other?

Comment 6

[Stuart Morgan]

We've had code to throw dialogs for UI requests from core when a sheet is already up for quite a while; I'd guess something in core changed around loading that just puts us in that case more often. We may need to look into whether there's some other way we could handle cookie requests that would give us more display control.

Comment 7

[Stuart Morgan]

Regressed between 2007-09-19 and 2007-09-20. Lots of activity, but I'm guessing maybe the event handling changes from bug 395397.

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I don't know that this needs to block a1 for sure, but we probably need to dig deeper really soon if there are broken Gecko changes that will need to be undone, as this is absolutely nasty when you hit it.

Comment 9

[Chris Lawson (gone)]

I wonder if bug 362729 is possibly related to this too. Are the proxy login dialogs coming from the same general code in Core?

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #9)
> I wonder if bug 362729 is possibly related to this too. Are the proxy login
> dialogs coming from the same general code in Core?

That bug dates to 1.0.2, so it's unlikely.

Comment 11

[Stuart Morgan]

So after reading bug 395397 and looking at stacks, this is definitely caused by that change. It's actually the intended purpose of it--continuing to process gecko events during modal runloops. That gives us better behaviors for things like menus being down, so I think it's a win overall and we just need to work around the strangeness in this specific case. I'm playing with that now.

Comment 12

[Stuart Morgan]

I haven't been having any luck here trying to sub-run the loop, so pushing out past a1 unfortunately.

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I added a note about this to the Known Issues section of the draft relnotes, as  think the "Ask" pref is something that might be more commonly employed among our wider alpha community.

Comment 15

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Is anything Steven is doing in bug 468393 going to affect this?

Comment 16

[Stuart Morgan]

I'm not actively looking at this; I may come back to it later, but I don't want to discourage others from looking by having my name on it while I'm busy with breakpad.

Comment 17

[Stuart Morgan]

Clearly this isn't going to happen for b4; we can still hope for 2.0 final though.

Comment 18

[Stuart Morgan]

My last round of investigation didn't get anywhere, so unfortunately this won't happen for 2.0.

Comment 20

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

If a patch shows up here, we'll take it, but given Stuart's investigations were never able to come up with a solution, that seems unlikely :-(

Comment 21

[BugMagnet]

this is a chronic issue
makes firefox vulnerable to mis-coded or malicious web pages.
just experienced this problem on www.RVLeakfinders.com
I kept clicking [deny] hundreds of times over about 5 minutes but could not close all the cookie set dialogs.
Finally, I had to force kill the FF process
seems an auto block is needed to prevent such cookie floods.
 Maybe limit them to one cookie request at a time if the [ask me each time] option is selected?

Comment 22

[Stuart Morgan]

You're in the wrong place; this is a Camino bug, and our cookie front-end is totally separate from Firefox's.