Last Comment Bug 457384 - A regular HTML block underneath a plug-in sometimes punches a hole in the plug-in
: A regular HTML block underneath a plug-in sometimes punches a hole in the plu...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on: 339548
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-26 23:10 PDT by Zack Weinberg (:zwol)
Modified: 2012-03-20 11:58 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Flash movie used by test cases (136 bytes, application/x-shockwave-flash)
2008-09-26 23:10 PDT, Zack Weinberg (:zwol)
no flags Details
source to flash movie (.fla) (48.00 KB, application/octet-stream)
2008-09-26 23:11 PDT, Zack Weinberg (:zwol)
no flags Details
test case 0a (control - doesn't show bug) (1.30 KB, text/html)
2008-09-26 23:13 PDT, Zack Weinberg (:zwol)
no flags Details
test case 0b (control - doesn't show bug) (1.29 KB, text/html)
2008-09-26 23:14 PDT, Zack Weinberg (:zwol)
no flags Details
test case 1a (does show bug) (1.30 KB, text/html)
2008-09-26 23:14 PDT, Zack Weinberg (:zwol)
no flags Details
test case 1b (does show bug) (1.29 KB, text/html)
2008-09-26 23:15 PDT, Zack Weinberg (:zwol)
no flags Details

Description Zack Weinberg (:zwol) 2008-09-26 23:10:32 PDT
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.
Comment 1 Zack Weinberg (:zwol) 2008-09-26 23:11:38 PDT
Created attachment 340697 [details]
source to flash movie (.fla)
Comment 2 Zack Weinberg (:zwol) 2008-09-26 23:13:46 PDT
Created attachment 340698 [details]
test case 0a (control - doesn't show bug)
Comment 3 Zack Weinberg (:zwol) 2008-09-26 23:14:11 PDT
Created attachment 340699 [details]
test case 0b (control - doesn't show bug)
Comment 4 Zack Weinberg (:zwol) 2008-09-26 23:14:54 PDT
Created attachment 340700 [details]
test case 1a (does show bug)
Comment 5 Zack Weinberg (:zwol) 2008-09-26 23:15:15 PDT
Created attachment 340701 [details]
test case 1b (does show bug)
Comment 6 Zack Weinberg (:zwol) 2008-09-26 23:17:48 PDT
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)
Comment 7 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-09-27 01:04:48 PDT
This is because overflow:auto elements get a widget, which is quite likely to be placed above the plugin in widget z-order.
Comment 8 Zack Weinberg (:zwol) 2008-09-27 11:43:30 PDT
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?
Comment 9 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-10-20 01:17:59 PDT
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.
Comment 10 Zack Weinberg (:zwol) 2009-07-01 10:02:22 PDT
I re-tested this with the "compositor phase 1" try server builds (https://build.mozilla.org/tryserver-builds/rocallahan@mozilla.com-try-f9bf8fa4178/) 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.
Comment 11 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-07-01 17:12:56 PDT
I suppose it would be better if we altered the widgets first and then repainted. Maybe I'll do that in compositor phase 2.
Comment 12 Zack Weinberg (:zwol) 2012-03-20 11:32:23 PDT
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?
Comment 13 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-03-20 11:58:05 PDT
You sometimes get the green flash on reload (while we're loading the plugin I guess), but not when toggling visibility of the plugin.

Note You need to log in before you can comment on or make changes to this bug.