|Summary:||REGRESSION (WebKit2): QuickTime (and Flash?) can draw outside the bounds of its containing frame when the frame is scrolled|
|Product:||WebKit||Reporter:||Adam Roben (:aroben) <aroben>|
|Priority:||P2||Keywords:||InRadar, PlatformOnly, Regression|
|Version:||528+ (Nightly build)|
|URL:||data:text/html,<iframe src="data:text/html,<embed src='http://trailers.apple.com/movies/fox/rio/rio-tlr1_r640s.mov' autoplay=true width=640 height=288>"></iframe>|
Description Adam Roben (:aroben) 2011-05-13 11:44:10 PDT
To reproduce: 1. Go to data:text/html,<iframe src="data:text/html,<embed src='http://trailers.apple.com/movies/fox/rio/rio-tlr1_r640s.mov' autoplay=true width=640 height=288>"></iframe> 2. When the movie starts playing, click in the righthand side of the horizontal scroll gutter You'll see a flash of the movie to the right of the iframe as the iframe scrolls. This bug does not occur in WebKit1.
Comment 1 Adam Roben (:aroben) 2011-05-13 11:46:25 PDT
When the iframe scrolls, two things happen: 1) We update the plugin's window region so that the part of the plugin that is supposed to be exposed after scrolling is the only part that can be drawn. 2) We move the plugin's window to match the new position after scrolling. The plugin is drawing between (1) and (2). At this point, the clip region has been updated to the part of the plugin that was formerly scrolled off the right edge of the iframe. The plugin is now drawing outside of the iframe's bounds. Then the plugin's window is moved into its new position, moving the clip region back inside the iframe's bounds.
Comment 2 Adam Roben (:aroben) 2011-05-13 11:48:00 PDT
WebKit1 works around this by setting plugins' window regions to an empty rect during scrolling, then restoring the correct window region afterward. That way the plugin will have no chance to draw when it's clipping region has been updated but its position hasn't.
Comment 3 Adam Roben (:aroben) 2011-05-13 11:49:21 PDT
The PluginQuirkDontClipToZeroRectWhenScrolling quirk in WebCore is related to the above-described WebKit1 fix. Apparently Java doesn't like this. See <http://trac.webkit.org/changeset/29974>. r29974 also implies that this will happen with Flash, too. We should test!