Closed Bug 495035 Opened 15 years ago Closed 8 years ago

FF35b5pre (20090526) displays blank cookie dialog

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows Vista
defect
Not set
critical

Tracking

(status1.9.1 wanted)

RESOLVED WORKSFORME
Tracking Status
status1.9.1 --- wanted

People

(Reporter: ilkkap, Unassigned)

References

()

Details

(Keywords: regression, relnote)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1pre) Gecko/20090526 Shiretoko/3.5pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1pre) Gecko/20090526 Shiretoko/3.5pre (.NET CLR 3.5.30729)

Cannot reproduce with any other site so far, just this http://yle.fi/uutiset/kotimaa/2009/05/raskas_organisaatio_maksoi_miljoonia_akelle_758848.html page makes FF to display blank cookie dialog.

Reproducible: Always

Steps to Reproduce:
1. Go to http://yle.fi/uutiset/kotimaa/2009/05/raskas_organisaatio_maksoi_miljoonia_akelle_758848.html
2. Wait for the cookie dialog to pop up

Actual Results:  
Blank accept cookies dialog

Expected Results:  
The normal FF cookie dialog
Confirmed on Windows XP, latest trunk, and I see it also in the latest Firefox 3.0 version.
This is not a very old bug, stems from ~Dec 2008. Problem is that it is not 100% reproducible.
Component: General → Networking: Cookies
Keywords: regression
Product: Firefox → Core
QA Contact: general → networking.cookies
Version: unspecified → Trunk
Another curious behavior: 

1. Ctrl+click the link, so that it opens on a new tab in background. 
2. Wait that the page has loaded completely.
3. Click on the tab.
4. You see the Cookie dialog over this page. Close the dialog and you now see the page. 
5. Move the mouse anywhere.. FF will close the tab and open it in a new full browser window. With the blank cookie dialog again.

Happens only with that page, as far as I know, but I'll keep testing.
Yes I see indeed more, but this blank cookie bug seems an isolated case with its own regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=050ae62b7d9d&tochange=3d10285b201c
Blocks: 466057
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.1?
So far I haven't been able to reproduce this.
What are the exact steps to reproduce? What preferences should be set?
It's "Ask me every time" option for cookies.
That is what I used
Ok, I can reproduce this on windows.
>	cookie.dll!nsCookiePromptService::CookieDialog(nsIDOMWindow * aParent=0x03cb1c58, nsICookie * aCookie=0x0553b0e0, const nsACString_internal & aHostname={...}, int aCookiesFromHost=0, int aChangingCookie=0, int * aRememberDecision=0x0030c0f4, int * aAccept=0x0030c15c)  Line 69	C++
 	cookie.dll!nsCookiePermission::CanSetCookie(nsIURI * aURI=0x04726b58, nsIChannel * aChannel=0x04126cb0, nsICookie2 * aCookie=0x0553b0e0, int * aIsSession=0x0030c364, __int64 * aExpiry=0x0030c35c, int * aResult=0x0030c15c)  Line 382 + 0x4c bytes	C++
 	necko.dll!nsCookieService::SetCookieInternal(nsIURI * aHostURI=0x04726b58, nsIChannel * aChannel=0x04126cb0, nsDependentCString & aCookieHeader={...}, __int64 aServerTime=1243440587, int aFromHttp=0)  Line 1420	C++
 	necko.dll!nsCookieService::SetCookieStringInternal(nsIURI * aHostURI=0x04726b58, nsIPrompt * aPrompt=0x04874ab0, const char * aCookieHeader=0x04198178, const char * aServerTime=0x00000000, nsIChannel * aChannel=0x04126cb0, int aFromHttp=0)  Line 764 + 0x20 bytes	C++
 	necko.dll!nsCookieService::SetCookieString(nsIURI * aHostURI=0x04726b58, nsIPrompt * aPrompt=0x04874ab0, const char * aCookieHeader=0x04198178, nsIChannel * aChannel=0x04126cb0)  Line 709	C++
 	gklayout.dll!nsHTMLDocument::SetCookie(const nsAString_internal & aCookie={...})  Line 1774	C++
 	xpc3250.dll!nsIDOMHTMLDocument_SetCookie(JSContext * cx=0x03cb1ec0, JSObject * obj=0x029039c0, int id=18298492, int * vp=0x0030cc7c)  Line 9068 + 0x1a bytes	C++
 	js3250.dll!js_SetSprop(JSContext * cx=0x03cb1ec0, JSScopeProperty * sprop=0x03d4c500, JSObject * obj=0x029039c0, int * vp=0x0030cc7c)  Line 386 + 0x3d bytes	C++
 	js3250.dll!js_SetPropertyHelper(JSContext * cx=0x03cb1ec0, JSObject * obj=0x029039c0, int id=18298492, int cacheResult=1, int * vp=0x0030cc7c)  Line 4592 + 0x15 bytes	C++
 	js3250.dll!js_Interpret(JSContext * cx=0x03cb1ec0)  Line 4781 + 0x1a bytes	C++
 	js3250.dll!js_Execute(JSContext * cx=0x03cb1ec0, JSObject * chain=0x01190300, JSScript * script=0x07384000, JSStackFrame * down=0x00000000, unsigned int flags=0, int * result=0x0030cdf8)  Line 1633 + 0x9 bytes	C++
 	js3250.dll!JS_EvaluateUCScriptForPrincipals(JSContext * cx=0x03cb1ec0, JSObject * obj=0x01190300, JSPrincipals * principals=0x047c5d5c, const unsigned short * chars=0x07383ec0, unsigned int length=87, const char * filename=0x053e7d20, unsigned int lineno=0, int * rval=0x0030cdf8)  Line 5151 + 0x19 bytes	C++
 	gklayout.dll!nsJSContext::EvaluateStringWithValue(const nsAString_internal & aScript={...}, void * aScopeObject=0x01190300, nsIPrincipal * aPrincipal=0x047c5d58, const char * aURL=0x053e7d20, unsigned int aLineNo=0, unsigned int aVersion=0, void * aRetValue=0x0030cf9c, int * aIsUndefined=0x00000000)  Line 1440 + 0x42 bytes	C++
 	gkplugin.dll!_evaluate(_NPP * npp=0x075c0084, NPObject * npobj=0x048ff678, _NPString * script=0x0030cfd0, _NPVariant * result=0x0030cfc0)  Line 1569 + 0x4a bytes	C++
 	NPSWF32.dll!66e34ad6() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for NPSWF32.dll]	
 	NPSWF32.dll!66d3585f() 	
 	NPSWF32.dll!66e6223d() 	
 	NPSWF32.dll!66ef97a9() 	
 	NPSWF32.dll!66f0a8dc() 	
 	NPSWF32.dll!66ee1716() 	
 	NPSWF32.dll!66ec68d2() 	
 	NPSWF32.dll!66e7af94() 	
 	NPSWF32.dll!66e7afc5() 	
 	NPSWF32.dll!66e79df7() 	
 	NPSWF32.dll!66e7a62a() 	
 	NPSWF32.dll!66e7a93a() 	
 	NPSWF32.dll!66e7a9cb() 	
 	NPSWF32.dll!66dd377a() 	
 	NPSWF32.dll!66e36dbe() 	
 	NPSWF32.dll!66e32f14() 	
 	gkplugin.dll!nsNPAPIPluginInstance::SetWindow(nsPluginWindow * window=0x075bf7a4)  Line 1084 + 0x4e bytes	C++
 	gklayout.dll!nsObjectFrame::PaintPlugin(nsIRenderingContext & aRenderingContext={...}, const nsRect & aDirtyRect={...}, const nsPoint & aFramePt={...})  Line 1498	C++
 	gklayout.dll!nsObjectFrame::PaintPlugin(nsIFrame * aFrame=0x075c2350, nsIRenderingContext * aCtx=0x055ec408, const nsRect & aDirtyRect={...}, nsPoint aPt={...})  Line 1092	C++
 	gklayout.dll!nsDisplayGeneric::Paint(nsDisplayListBuilder * aBuilder=0x0030d914, nsIRenderingContext * aCtx=0x055ec408, const nsRect & aDirtyRect={...})  Line 874 + 0x2c bytes	C++
 	gklayout.dll!nsDisplayList::Paint(nsDisplayListBuilder * aBuilder=0x0030d914, nsIRenderingContext * aCtx=0x055ec408, const nsRect & aDirtyRect={...})  Line 318	C++
 	gklayout.dll!nsDisplayWrapList::Paint(nsDisplayListBuilder * aBuilder=0x0030d914, nsIRenderingContext * aCtx=0x055ec408, const nsRect & aDirtyRect={...})  Line 821	C++
 	gklayout.dll!nsDisplayClip::Paint(nsDisplayListBuilder * aBuilder=0x0030d914, nsIRenderingContext * aCtx=0x055ec408, const nsRect & aDirtyRect={...})  Line 1008	C++
 	gklayout.dll!nsDisplayList::Paint(nsDisplayListBuilder * aBuilder=0x0030d914, nsIRenderingContext * aCtx=0x055ec408, const nsRect & aDirtyRect={...})  Line 318	C++
 	gklayout.dll!nsLayoutUtils::PaintFrame(nsIRenderingContext * aRenderingContext=0x055ec408, nsIFrame * aFrame=0x02624724, const nsRegion & aDirtyRegion={...}, unsigned int aBackground=4294967295)  Line 1107	C++
 	gklayout.dll!PresShell::Paint(nsIView * aView=0x05461c60, nsIRenderingContext * aRenderingContext=0x055ec408, const nsRegion & aDirtyRegion={...})  Line 5638 + 0x15 bytes	C++
 	gklayout.dll!nsViewManager::RenderViews(nsView * aView=0x0553f6b8, nsIRenderingContext & aRC={...}, const nsRegion & aRegion={...})  Line 610	C++
 	gklayout.dll!nsViewManager::Refresh(nsView * aView=0x0553f6b8, nsIRenderingContext * aContext=0x055ec408, nsIRegion * aRegion=0x0553c408, unsigned int aUpdateFlags=1)  Line 513	C++
 	gklayout.dll!nsViewManager::DispatchEvent(nsGUIEvent * aEvent=0x0030e04c, nsEventStatus * aStatus=0x0030de4c)  Line 1107	C++
 	gklayout.dll!HandleEvent(nsGUIEvent * aEvent=0x0030e04c)  Line 170	C++
 	gkwidget.dll!nsWindow::DispatchEvent(nsGUIEvent * event=0x0030e04c, nsEventStatus & aStatus=nsEventStatus_eIgnore)  Line 967 + 0xc bytes	C++
 	gkwidget.dll!nsWindow::DispatchWindowEvent(nsGUIEvent * event=0x0030e04c, nsEventStatus & aStatus=nsEventStatus_eIgnore)  Line 993	C++
 	gkwidget.dll!nsWindow::OnPaint(HDC__ * aDC=0x00000000)  Line 6151 + 0x1e bytes	C++
So on Windows (and only on Windows, after bug 459244 got fixed), we call SetWindow() on every paint.  It looks like in this case Flash decides to run some script, including setting cookies, during said call...

If this is allowed, we need to stop calling SetWindow from paint.
Component: Networking: Cookies → Plug-ins
QA Contact: networking.cookies → plugins
And the SetWindow call seems to date back to bug 109041, with the condition getting somewhat changed in bug 116108.

Note that on m-c doupdatewindow is only used in the OS/2 branch of the code (and should probably move there).

In any case, the fact that JS runs under painting is a critical bug in either our code or in the Flash plug-in.  I don't know which, offhand.

Oh, and with Flash disabled this bug does go away.
Severity: normal → critical
So is this a regression? The range indicated by Ria in comment 4 indicts a bug that was also landed on 3.0.x, which would imply this regressed there, as well?
Well, bug 466057 made this particular case visible, but bug 466057 didn't cause
this.
So is this really a regression then?
We should determine if this is us or flash, as per comment 11. Kev, to add to your list of items to track down with our friends at Adobe.

Jim: can you also take a peek and see if there's something obvious we can do to get around this?

Finally, doesn't block as there are some workarounds, but I'll relnote it.
Flags: wanted1.9.1.x?
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Keywords: relnote
I see the white cookies also in Firefox 3.0, but not the terrible hangs like in latest trunk. 
If you wait half a minute before responding to the cookie, it locks up and only wiping over the (translucent) cookie dialog with the taskmanager can end it. The hangs only started in the last month.
I'm unable to reproduce in the latest 1.9.1 nightly. Regardless, window->window is null when the view changes in paint, so this looks like it's our first chance to call set window on the plugin and is needed.
I can reproduce the both behaviors with the Gecko/20090529 Shiretoko/3.5pre.
status1.9.1: --- → ?
Flags: wanted1.9.1.x?
We don't use browser cookies so it won't be flash.
  Cant reproduce?   NOT FLASH?  IS SO FLASH/... Adobe did this to all of us when we updated the lated version... all Macs and PCs (if firefox for PC)

I can reproduce on any gaming site which requires frames to open in rounds (like during tournaments)

i get blank screens/frames all over (not cookie windows) but all frames after 2 or 3 are opened, become blank (all gaming sites etc) and doesnt reload until i do a browser shut down and restart...       

i have lost tons of money playing backgammon online and been searching for fix for this... has been ever since the flash update on my mac 7 months ago.. totallt broke flash in all of my browsers tho originated in Firefox.. my FF is unusable now most days... have read all about this all over internet in forums where folks are having a hell of a time but Adobe refuses to acknowledge or fix the problem...
ever since the adobe flash update a few months ago (to current version) all of my frames in ANY browser now do this and go blank after 2-3 normal ones... this was supposed to be a backgammon table as i was in round 5 of a tournament...  
(i of course lost all my money since i couldnt see to play)

This began in Firefox but now affects all broswers if u updated yr Flash originally FROM Firefox..
Do any NS_ASSSERTIONs fail when this bug occurs?
I'm seeing occasional blank cookie dialogues in OS X, usually on a site with large numbers of cookies to set. (4.0b8pre) The app doesn't hang, but that window becomes effectively useless and if it is the only window, a Force Quit is required. I'm trying to trip it in a debug build so I can see if assertions appear, but the bug is intermittent as per the initial report.
I tested on  Windows Vista x86 with FF latest release 46.0 and latest Nightly 49.0 and I can't reproduce the issue.
Notice that "Ask me every time" option for cookies is no more available according to: https://support.mozilla.org/en-US/questions/1106599
Please retest this on the latest Firefox version and see if you can reproduce the problem.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: