Flash plugin mispositioned when scrolling

RESOLVED FIXED

Status

()

P1
normal
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: sylvain.pasche, Assigned: roc)

Tracking

({regression, testcase})

Trunk
x86
Windows NT
regression, testcase
Points:
---
Bug Flags:
blocking1.9.2 +

Firefox Tracking Flags

(status1.9.2 beta1-fixed)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

9 years ago
Created attachment 391621 [details]
testcase

When scrolling with the wheel or up/down keys, flash plugin element sometimes doesn't scroll and appears above the surrounding text. That's a regression from bug 505896.

See testcase, I couldn't reproduce the issue with the test plugin.
Flags: blocking1.9.2?
Assignee: nobody → roc
Flags: blocking1.9.2? → blocking1.9.2+
Created attachment 393085 [details]
testcase#2

I can reproduce this reliably by loading this slightly modified testcase and pressing page-down then page-up --- the plugin is gone. I've removed the inner DIVs, this is really simple.
Created attachment 393094 [details] [diff] [review]
fix

This fixes it. Because ConfigureChildren has short-circuit paths now that depend on the widget's mBounds being correct, we need to update mBounds to account for the effects of ScrollWindowEx before we call ConfigureChildren.
Attachment #393094 - Flags: review?(jmathies)
I'm not sure why the test plugin isn't affected by this. With wmode=window, it should be affected, but doesn't seem to be. But even if it was, we can't really write a test here, since the widget's mBounds always looks correct, the bug is that the HWND ends up in the wrong position.
Whiteboard: [needs review]

Updated

9 years ago
Attachment #393094 - Flags: review?(jmathies) → review+
This patch isn't right since we iterate over the children in aConfigurations but not other children we may have. It's also not right because ScrollWindowEx is supposed to send WM_MOVE messages to the child windows which should be updating our mBounds, so this patch shouldn't even be necessary.
Ah, but plugin window messages don't go through nsWindow::WindowProc. So that code never gets called...
Created attachment 393974 [details] [diff] [review]
fix

Sorry Jim, this patch makes more sense.
Attachment #393094 - Attachment is obsolete: true
Attachment #393974 - Flags: review?(jmathies)

Updated

9 years ago
Attachment #393974 - Flags: review?(jmathies) → review+
Duplicate of this bug: 512167

Updated

9 years ago
Duplicate of this bug: 511816
This looks like its fixed, see testcase in bug 511816.
http://hg.mozilla.org/mozilla-central/rev/7af754a937d6
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: [needs review]
Needs a 1.9.2 branch push.

Comment 13

9 years ago
Comment on attachment 393974 [details] [diff] [review]
fix

This doesn't need approval because it's a blocker, but I'll mark it anyway!
Attachment #393974 - Flags: approval1.9.2? → approval1.9.2+
Whiteboard: [needs 192 landing]
Priority: -- → P1
Looks like roc landed this on 1.9.2, as part of this push on 9/23:
http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?changeset=c46bf0f0d355

 main fix:    http://hg.mozilla.org/releases/mozilla-1.9.2/rev/c46bf0f0d355
 bustage fix: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/33c9121a6bdc
status1.9.2: --- → beta1-fixed
Whiteboard: [needs 192 landing]
You need to log in before you can comment on or make changes to this bug.