Closed Bug 611206 Opened 9 years ago Closed 9 years ago

[OOPP]vertical or horizontal mouse coordinates are off when inside the plugin and moving the mouse over the globe after page scrolled

Categories

(Core :: Plug-ins, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla2.0
Tracking Status
blocking2.0 --- beta8+

People

(Reporter: mozbugz, Assigned: benjamin)

References

()

Details

(Keywords: regression)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101110 Firefox/4.0b8pre
Build Identifier: 

Vertical mouse coordinates are off for some reason on this URL:
https://genographic.nationalgeographic.com/genographic/lan/en/globe.html
when trying to manipulate the globe.

Reproducible: Always

Steps to Reproduce:
1. Move mouse over globe
2. Notice no hand icon
3. move mouse down about 3 vertical inches.
Actual Results:  
mouse hand show up

Expected Results:  
hand mouse icon should be inline with the coordinates as the mouse pointer.

This the type of bug we saw on www.silverlight.net/showcase. The mouse coordinates where off by some specific known value in the vertical space.  Now this globe had the same problem except its on Flash.
Blocks: 596451
Summary: vertical mouse coordinates are off when inside the plugin. → vertical mouse coordinates are off when inside the plugin and moving the mouse over the globe
it is not only vertical but also horizontal.
Yeah, I noticed that a bit after I filed this, the first build I tested it seemed only like it was really a problem and reproduce able in the vertical direction, but I've noticed too that it can be way off in both directions.
Summary: vertical mouse coordinates are off when inside the plugin and moving the mouse over the globe → vertical or horizontal mouse coordinates are off when inside the plugin and moving the mouse over the globe
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Version: unspecified → Trunk
OS: Windows 7 → All
Hardware: x86 → All
Another example is the map on this page: http://www.radioreference.com/apps/audio/
This affects www.Silverlight.net/showcase again. I believe this means that bug 547353 is back: https://bugzilla.mozilla.org/show_bug.cgi?id=596451#c33 :)
OS: All → Windows 7
This is not a Windows 7 only bug.  I easily reproduce it on Windows XP.
OS: Windows 7 → All
http://www.tbs.com/video/index.jsp

Also happens on this page.  If you scroll down at all, you can't click any of the buttons in the video player.  It functions correctly if you don't scroll at all.
Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101110 Firefox/4.0b8pre

Able to reproduce with http://www.radioreference.com/apps/audio/. Vertical mouse coordinates are not matching with the hand icon.
"Build worked : 
Mozilla/5.0 (Windows; Windows NT 6.1; en-US; rv:2.0b2pre) Gecko/20100715 Minefield/4.0b2pre
http://hg.mozilla.org/mozilla-central/rev/5fda39cd703c

Build broken : 
Mozilla/5.0 (Windows; Windows NT 6.1; en-US; rv:2.0b2pre) Gecko/20100716 Minefield/4.0b2pre
http://hg.mozilla.org/mozilla-central/rev/96de199027d7

pushlog : 
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5fda39cd703c
&tochange=96de199027d7"
(In reply to comment #8)
> "Build worked : 
> Mozilla/5.0 (Windows; Windows NT 6.1; en-US; rv:2.0b2pre) Gecko/20100715
> Minefield/4.0b2pre
> http://hg.mozilla.org/mozilla-central/rev/5fda39cd703c
> 
> Build broken : 
> Mozilla/5.0 (Windows; Windows NT 6.1; en-US; rv:2.0b2pre) Gecko/20100716
> Minefield/4.0b2pre
> http://hg.mozilla.org/mozilla-central/rev/96de199027d7
> 
> pushlog : 
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5fda39cd703c
> &tochange=96de199027d7"
It is different bug. SeeBug 607213
I'm confused. Is this a direct dup of bug 607213? It looks that way, but I want to be sure I'm not missing something.
It happens only OOPP on.

D2D  D3D10 IPC
ON    ON      ON    happens
ON    ON      OFF   not
ON    OFF    ON    happens
ON    OFF    OFF   not
OFF   ON     ON    happens
OFF   ON     OFF   not
OFF   OFF   ON    happens
OFF   OFF   OFF   not

http://hg.mozilla.org/mozilla-central/rev/0f17e5f1eb01
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101111 Firefox/4.0b8pre ID:20101111042449
Summary: vertical or horizontal mouse coordinates are off when inside the plugin and moving the mouse over the globe → OOPP]vertical or horizontal mouse coordinates are off when inside the plugin and moving the mouse over the globe after page scrolled
Summary: OOPP]vertical or horizontal mouse coordinates are off when inside the plugin and moving the mouse over the globe after page scrolled → [OOPP]vertical or horizontal mouse coordinates are off when inside the plugin and moving the mouse over the globe after page scrolled
blocking2.0: --- → ?
Target Milestone: --- → mozilla2.0
Scrolling webpages is common, this should block beta8.
blocking2.0: ? → beta8+
roc/karl, what's the right way to tell when a plugin changes position (relative to the toplevel widget)? Is it nsObjectFrame::Reflow? And how does that interact with the visibility notifications received at nsDisplayPlugin::GetWidgetConfiguration/ComputeWidgetGeometry?
Blocks: 609580
No longer blocks: 609580
(In reply to comment #5)
> This is not a Windows 7 only bug.  I easily reproduce it on Windows XP.

Unfortunately we don't have 'Windows' only as a bugzilla item, probably need that added since we run into it often in bugzilla :)  Technically this doesn't really fall into ALL, since ALL refers to ALL OS's and this is a direct problem with Windows async not Linux or Mac.
This needs an owner. Benjamin, if you're not it, please reassign.

Roc, Karl, can you have a look at bsmedberg's question in comment 13?
Assignee: nobody → benjamin
(In reply to comment #13)
> roc/karl, what's the right way to tell when a plugin changes position (relative
> to the toplevel widget)?

My understanding is that WM_WINDOWPOSCHANGED is the way to tell a windowless plugin that it changes position in the native window.  As we only sent that during paint, I don't know how it worked even before bug 564991 (but it explains why things got worse after bug 564991 - e.g. bug Bug 607213 - because with retained layers we paint less.)

The window.x and .y coordinates are not position indicators for windowless plugins; they merely tell the plugin where to draw into the drawable, which may or may not be aligned with any native window.  However, I gather that silverlight was misinterpreting this.

> Is it nsObjectFrame::Reflow?

Relflow will not be called when scrolling.

> And how does that interact with the visibility notifications received at
> nsDisplayPlugin::GetWidgetConfiguration/ComputeWidgetGeometry?

These should be reliable indicators of position change (even scrolling).
I would suggest checking mWindowlessRect in ComputeWidgetGeometry, in the same way as it is checked in PaintPlugin.
Not sure its realated, but another test case maybe:  

Go to www.msnbc.com 
Zoom in a couple of steps 
Visit the URL: http://www.msnbc.msn.com/id/40126918/ns/travel-cruise_travel/
Scroll down , neat the end - there is a video clip
Note you cannot click and get the video to play
Un-zoom the page without leaving, now the video will play when clicked

Strangely enough, you can now zoom again and it 'still works' but only for that time, on that page.
To add to what Karl said, nsObjectFrame::ComputeWidgetGeometry is called every time the plugin moves for any reason.
Basic testing says this solves the problem, but I haven't run extensive tests on it. I should also probably come up with a way of testing it... shouldn't be too hard.
Attachment #489927 - Flags: review?(karlt)
Comment on attachment 489927 [details] [diff] [review]
Send position changes via the geometry callback, rev. 1

Looks good.

The "origin" code in FixupWindow is now unnecessary except on XP_MACOSX.

A comment in ComputeWidgetGeometry mentioning that "UpdateWindowVisibility"
will (also) notify of origin changes might be helpful.
Attachment #489927 - Flags: review?(karlt) → review+
(In reply to comment #16)
> My understanding is that WM_WINDOWPOSCHANGED is the way to tell a windowless
> plugin that it changes position in the native window.  As we only sent that
> during paint, I don't know how it worked even before bug 564991.

> However, I gather that silverlight was misinterpreting this.

The silverlight issue seems to go way back I guess, most notably: bug 356084, bug 536429 comment 16 and bug 547353.
For whatever the reason it doesn't happen in youtube videos...
(In reply to comment #23)
> For whatever the reason it doesn't happen in youtube videos...

It does happen with Youtube videos when embedded on another page though.. Changing dom.ipc.plugins.enabled to false will temporarily bypass this issue by disabling OOPP (only thing currently affected by async painting) until this lands.
http://hg.mozilla.org/mozilla-central/rev/106efcaa0590

Although the test is failing, so I may disable the test for now. Karl, can you look over the test and see if there's anything really dumb I'm doing wrong? The failure is:

ERROR TEST-UNEXPECTED-FAIL | /tests/modules/plugin/test/test_positioning.html | Window should be informed of its new position. - got -695, expected -776

I got some of these errors when the page height was not as big as the window height, but the page height is now 10000 pixels, so I don't see how that can be a problem.
I'm guessing a bit here, but maybe the initial position of the plugin could be wrong because the changes from reflow have not been included.  AFAIK reflow has not necessarily happened at onload.
p.offsetHeight should force a reflow I expect.
81 pixels seems too many to be explained by that but it would be correct to force a reflow when testing positions, so worth a try.
Hrm, it waits for first-paint before getting the initial position. My current theory is that the entire iframe in which the test is loaded is changing position because of scrolling in the outer mochitest framework. I might commit some testing code to debug that theory.

Anyway, I'm going to mark this FIXED and deal with the test a bit later.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
(In reply to comment #27)
> Hrm, it waits for first-paint before getting the initial position.

Yes, but that first paint can happen after the first AsyncSetWindow IIRC, which is not necessarily after the whole page has been reflowed.
You need to log in before you can comment on or make changes to this bug.