Closed Bug 607213 Opened 14 years ago Closed 14 years ago

Disabling hardware acceleration results in windowless plugin misalignment on page scroll [mouse input coordinates offset]

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: fehe, Unassigned)

References

(
URL
)

Details

(Keywords: regression, ux-natural-mapping)

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.
URL: http://watch.ctv.ca
Severity: normal → major
Regression window: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5fda39cd703c&tochange=96de199027d7 Likely candidate: bug 564991
Blocks: 564991
blocking2.0: --- → ?
Component: Graphics → Layout
Keywords: regression, ux-natural-mapping
QA Contact: thebes → layout
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]
Perhaps related to WM_WINDPOSCHANGED like bug 601064 (which is different).
Depends on: 601064
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.
No longer depends on: 601064
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: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.