The hulu.com homepage video doesn't play if you have async layers enabled. On Linux, and now that I have a working impl on Windows, on Windows either. It's quite possible that this is a timing issue with the particular actionscript on this page, but I don't think we can land async-layers on Winows without knowing what's going on here. Karl, giving this to you at first, but we should feel free to bring in contacts at Hulu and/or Adobe to help diagnose if you can't find an obvious explanation.

Oh, and if you can't get to hulu from NZ, you can tunnel through MV to get access.

Is there are any other page with the same problem? I'm not able to use this page because it is US only

I don't know of another page with this problem, no.

I can reproduce. Also, after resizing the browser window wide enough, I get this crash: #5 0x00007ff2b6fddce8 in gfxASurface::CairoSurface (this=0x0) at ../../dist/include/gfxASurface.h:117 #6 0x00007ff2b8400259 in gfxContext (this=0x7ff29b1200a0, surface=0x0) at /home/karl/moz/dev/gfx/thebes/gfxContext.cpp:64 #7 0x00007ff2b80d45b4 in mozilla::plugins::PluginInstanceChild::PaintRectToSurface (this=0x7ff2ab4af6b0, aRect=..., aSurface=0x7ff29b11f540, aColor=...) at /home/karl/moz/dev/dom/plugins/PluginInstanceChild.cpp:2364 #8 0x00007ff2b80d4a9a in mozilla::plugins::PluginInstanceChild::PaintRectWithAlphaExtraction (this=0x7ff2ab4af6b0, aRect=..., aSurface=0x7ff29b11f400) at /home/karl/moz/dev/dom/plugins/PluginInstanceChild.cpp:2414 #9 0x00007ff2b80d507b in mozilla::plugins::PluginInstanceChild::ShowPluginFrame (this=0x7ff2ab4af6b0) at /home/karl/moz/dev/dom/plugins/PluginInstanceChild.cpp:2478 #10 0x00007ff2b80d54d8 in mozilla::plugins::PluginInstanceChild::InvalidateRectDelayed (this=0x7ff2ab4af6b0) at /home/karl/moz/dev/dom/plugins/PluginInstanceChild.cpp:2531 #11 0x00007ff2b80d7c36 in DispatchToMethod<mozilla::plugins::PluginInstanceChild, void (mozilla::plugins::PluginInstanceChild::*)()> (obj=0x7ff2ab4af6b0, method=0x7ff2b80d5486 <mozilla::plugins::PluginInstanceChild::InvalidateRectDelayed()>, arg=...) at /home/karl/moz/dev/ipc/chromium/src/base/tuple.h:383 #12 0x00007ff2b80d7b86 in RunnableMethod<mozilla::plugins::PluginInstanceChild, void (mozilla::plugins::PluginInstanceChild::*)(), Tuple0>::Run ( this=0x7ff29b11f3c0) at /home/karl/moz/dev/ipc/chromium/src/base/task.h:307 #13 0x00007ff2b8376430 in MessageLoop::RunTask (this=0x7fffd63eaa70, task=0x7ff29b11f3c0) at /home/karl/moz/dev/ipc/chromium/src/base/message_loop.cc:343 #14 0x00007ff2b83764a0 in MessageLoop::DeferOrRunPendingTask ( this=0x7fffd63eaa70, pending_task=...) at /home/karl/moz/dev/ipc/chromium/src/base/message_loop.cc:351 #15 0x00007ff2b837689e in MessageLoop::DoWork (this=0x7fffd63eaa70) at /home/karl/moz/dev/ipc/chromium/src/base/message_loop.cc:451 #16 0x00007ff2b83eab72 in base::MessagePumpForUI::RunWithDispatcher ( this=0x7ff2ab406260, delegate=0x7fffd63eaa70, dispatcher=0x0) at /home/karl/moz/dev/ipc/chromium/src/base/message_pump_glib.cc:199 #17 0x00007ff2b83eb1c2 in base::MessagePumpForUI::Run (this=0x7ff2ab406260, delegate=0x7fffd63eaa70) at /home/karl/moz/dev/ipc/chromium/src/base/message_pump_glib.h:59 #18 0x00007ff2b8375f3b in MessageLoop::RunInternal (this=0x7fffd63eaa70) at /home/karl/moz/dev/ipc/chromium/src/base/message_loop.cc:219 #19 0x00007ff2b8375ec0 in MessageLoop::RunHandler (this=0x7fffd63eaa70) at /home/karl/moz/dev/ipc/chromium/src/base/message_loop.cc:202 #20 0x00007ff2b8375e51 in MessageLoop::Run (this=0x7fffd63eaa70) at /home/karl/moz/dev/ipc/chromium/src/base/message_loop.cc:176 #21 0x00007ff2b6bc988a in XRE_InitChildProcess (aArgc=2, aArgv=0x7fffd63eae28, aProcess=GeckoProcessType_Plugin) at /home/karl/moz/dev/toolkit/xre/nsEmbedFunctions.cpp:506 mHelperSurface is null (and I assume it should not be).

It seems that the CSS visibility of the plugin is changed from hidden to visible after instantiation. However, nsObjectFrame::CallSetWindow returns early when hidden and so the plugin does not get its AsyncSetWindow call. Some possible solutions are: 1) Do AsyncSetWindow from CallSetWindow even when hidden. 2) Record whether AsyncSetWindow has been called, and call it during the first paint, if not already called. 3) Register the plugin for geometry updates and AsyncSetWindow on change. The patch in bug 583109 does this and I expect would fix this bug.

Ah, should be pretty easy to create a testcase then. I'll try that soon. Currently I believe that plugins which are hidden (background tabs, etc) still send paint updates. There are two ways that we could suppress painting for background tabs: A) call AsyncSetWindow with a flag to suppress painting B) Invent a new API for paint suppression/unsuppression If we do A, then we should just hook AsyncSetWindow up to geometry updates, but then we might have to deal with bug 601064. Option B would fix bug 601064 and we could just call AsyncSetWindow from CallSetWindow and immediately suppress painting, but will probably require interface changes.

See also bug 596451 part G, which solves a related timing issue. This code is too complicated, we should really come up with some better invariants.

For bug 601064, I think we just need to ensure we ask the plugin to paint once at the beginning even if it's not visible. That should be pretty easy.

This patch works when applied on top of bug 583109.

The updated patch in bug 583109 subsumes this patch, and this will be fixed when the maple branch lands.

Fixed with the commit of bug 583109, http://hg.mozilla.org/mozilla-central/rev/bdbef533364f