Created attachment 340696 [details]
Flash movie used by test cases
An HTML block element with overflow:auto (probably also overflow:scroll, but I didn't try that) will, under some conditions, prevent mouse clicks within its bounding rectangle from signaling events to a plug-in whose block is above it in the z-order. The scroll bars do not have to be showing for this to happen, and in fact there doesn't have to be any content at all within the overflow:auto block.
The loss of mouse clicks is cross-platform. These conditions also cause visual glitches, but those are platform-dependent. On Linux, when in the state that loses events, whatever is directly underneath the plug-in shows through in the problem rectangle. (This is not necessarily the content of the overflow:auto element -- the effect can reach through several z-layers.) On Windows, that doesn't happen, but changes from script to the content of the overflow:auto element sometimes cause visible flashes of the problem rectangle.
I'm going to attach four .html files plus one Flash movie (.swf) and its source (.fla). All of the HTML files will be visually identical when first loaded: there will be three buttons at the top of the screen and then (assuming you have the Flash plug-in) a large blue rectangle below that, with a hollow black square inside. Clicking the "Toggle embed" button will hide the movie, revealing a box with some filler text inside and possibly a scrollbar, in the same position relative to the viewport as the hollow black square. Clicking "Toggle embed" again will bring the movie back. When the movie is visible, clicking anywhere within the blue rectangle -- including within the hollow black square -- will change it to purple for as long as the mouse is held down. Take note of the page title, which will end in a case number: 0a, 0b, 1a, or 1b.
If you click the "Toggle scroller" button while the movie is visible, nothing will appear to happen, but under the hood, the box with the filler text has been changed to display:none. Clicking anywhere within the blue rectangle should still change it to purple. Now click "toggle scroller" again. If you're on Linux, and you're looking at case 1a or 1b, you should see most of the area within the hollow black square turn lime green. Whether or not you're on Linux, if you're looking at case 1a or 1b, you should find that most of the area within the hollow black square (exactly the area that turns lime green) is now unresponsive to clicks. If you are looking at case 0a or 0b (which use overflow:hidden instead of overflow:auto on the box underneath) none of these errors will happen.
Clicking "Toggle embed" twice at this point will restore the movie to proper working order.
Clicking "Scribble on scroller" may or may not cause visual effects, depending on platform and possibly other conditions; the real web application that this was reduced from reliably showed flicker when the content of the scroller changed, on Windows and not on Linux, but I couldn't reproduce it with the reduced case myself.
Created attachment 340697 [details]
source to flash movie (.fla)
Created attachment 340698 [details]
test case 0a (control - doesn't show bug)
Created attachment 340699 [details]
test case 0b (control - doesn't show bug)
Created attachment 340700 [details]
test case 1a (does show bug)
Created attachment 340701 [details]
test case 1b (does show bug)
If you look at the test cases inside Bugzilla, you of course don't get the Flash movie, since the url in the embed tag is wrong; but I just noticed that double-clicking on "Toggle scroller" still makes a lime square appear within the blank white area where the movie is supposed to be. (on linux, of course)
This is because overflow:auto elements get a widget, which is quite likely to be placed above the plugin in widget z-order.
So the widget z-order is getting out of sync with the frame z-order? Is there any time when we *have* to do that?
No, but in general it's a real pain to figure out how to put widgets in the right z-order, because CSS z-ordering is complex. The most important thing to do here is to implement compositor so we don't have HTML content with widgets of its own.
I re-tested this with the "compositor phase 1" try server builds (https://firstname.lastname@example.org/) on Windows (XP, virtual machine) -- I cannot reproduce the original bug anymore. However, in all four test cases there is now a brief green flash when the embed goes from display:none to visible; it appears that the CSS background of the embed is getting painted, that's flushed, and only then is the plugin getting a chance to paint.
I suppose it would be better if we altered the widgets first and then repainted. Maybe I'll do that in compositor phase 2.
It seems very likely that this is fixed now -- compositor landed a long time ago -- but I no longer have convenient access to Windows. Can someone retest, please?
You sometimes get the green flash on reload (while we're loading the plugin I guess), but not when toggling visibility of the plugin.