Closed Bug 607213 Opened 9 years ago Closed 9 years ago
Disabling hardware acceleration results in windowless plugin misalignment on page scroll [mouse input coordinates offset]
Here's a bug I encounter with regularity, and on many sites: with layers.accelerate-all set to false (disabled), I encounter flash plugin misalignment that is somewhat dependent on scroll position. I notice the misalignment after scrolling a page and then trying to click on the player controls then either have to scroll the page to find the location where it lines up again or move my mouse around a bit to find the region, near the flash object, where the controls have shifted to. STR: 1. Launch Minefield with a new profile 2. Set layers.accelerate-all to false and restart 3. Visit http://watch.ctv.ca 4. Wait for the ad to finish playing and whatever main video to start. Subsequently, you may pause the video, if you wish. 5. Make sure you have not maximized the window. Allow at least a third of the page to be vertically scrollable. 6. Mouseover the video player's volume control icon. Notice that volume control flies out. 7. Click (DO NOT HOLD) the bottom vertical scroll arrow to "single-scroll" the page down (by the default number of lines) 8. Mouseover the player's volume control icon again, to see if it is still responsive. If it is, repeat Step 7 until it is no longer responsive. 9. Compare with layers.accelerate-all enabled.
Regression window: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5fda39cd703c&tochange=96de199027d7 Likely candidate: bug 564991
All sites with windowless plugins are affected. You can verify by comparing the effect scrolling has on input coordinates alignment between the plugins attached to bug 561818. For the windowless case, there is misalignment. For the windowed case, there is no misalignment. Youtube video players are windowed and are not affected Some additional sites affected (a very limited sample set): 1. http://www.hulu.com 2. http://abcnews.go.com/video 3. http://abcnews.go.com/nightline 4. http://www.cnn.com/video/ 5. http://www.bestbuy.com/site/index.jsp (input coordinates for the big flash ad become misaligned with page scrolling) 6. etc.
Summary: Disabling hardware acceleration results in plugin misalignment on page scroll → Disabling hardware acceleration results in windowless plugin misalignment on page scroll [mouse input coordinates offset]
I don't see how this can be related to bug 601064, and I seriously doubt that fixing bug 601064 will fix this bug. Furthermore, this bug was introduced in July 15, 2010, whereas the bug 601064 regression shows a date of October 27, 2009. I'm seriously considering removing the bug 601064 dependency, unless someone can explain why bug 601064 will fix this.
Here's another example: http://www.radioreference.com/apps/audio/ Mouse coordinates for the map on the page are way off when the page is scrolled.
This is with OOPP on? Does it also happen with OOPP off? This is thoroughly weird, I'll investigate.
blocking2.0: ? → betaN+
Can anyone reproduce this with today's nightly (10/11)? This may have been fixed by accident along with bug 596451. FWIW, I cannot.
This reproducible with today's nightly; and yes it happens only with OOPP on.
http://www.cnn.com/video/ http://abcnews.go.com/video Prior to landing of bug 596451, It is regardless of OOPP status. It Happens only disabled D2D and D3D10 both. After landing bug 596451, It happens only enabled OOPP. It happens regardless of D2D and D3D10 either.
Sorry ignore comment #9 http://www.cnn.com/video/ http://abcnews.go.com/video Prior to landing of bug 596451, It is regardless of OOPP status. It Happens only disabled D2D and D3D10 both. After landing bug 596451, now investigating
Can I get STR again? My current steps are: * set gfx.direct2d.disabled to true * set layers.accelerate-all to false * restart * visit http://abcnews.go.com/video All mouse interactions appear to be correct with today's nightly (Windows 7 Aero on).
Comment#9 is correct After landing bug 596451, It happens only enabled OOPP. It happens regardless of D2D and D3D10 either.
Aha, it's the "after scrolling" bit I was missing. We're not sending WM_WINDOWPOSCHANGED (or setwindow) messages when we scroll, so the mouse message positions are wrong. jmathies, do you know if we need to send both setwindow and WM_WINDOWPOSCHANGED, or just WM_WINDOWPOSCHANGED when we scroll?
According to Comment #9, This was fixed by bug 596451 accidentally. However, new bug 611206 happens by regression of bug 596451.
ok, let's call this fixed and I'll take the other one.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.