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.

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.

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 :)

This is not a Windows 7 only bug. I easily reproduce it on Windows XP.

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

Scrolling webpages is common, this should block 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?

(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?

(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.

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.

(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.

(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.