[locked] Flash player crashes all browsers

Created an attachment (id=379855) [details]
Printscreen of the blank 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.

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

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.

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.

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.

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.

We don't use browser cookies so it won't be flash.