User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100219 Minefield/3.7a2pre (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100219 Minefield/3.7a2pre The mouse coordinates are misaligned for the Silverlight plugin on the Silverlight Showcase page. This problem does not exist when IPC plugins is disabled. Tested using Silverlight 4 Beta plugin. Reproducible: Always Steps to Reproduce: 1. Visit the linked URL 2. Wait for the "Showcase" Silverlight plugin to fully load 3. Notice as you move your mouse from one end of each of those tiles to the other (i.e. top to bottom, left to right) that the adjacent tile gets highlighted/selected, without even pointing at it. 4. If you click any of the tiles, notice that you cannot click either the "View Now" or close buttons, if you're directly over them. You have to fish around to find the point where the buttons get highlighted.

I see that also on Windows 7. Silverlight y mouse coordinates are relative to the browser scrolling and plugin position with the above URL; similar to the position issues found with Shockwave bug 543201 and Flash bug 536369. If I move over squares up and down, it looks relative to 1 square distance. If I do that and then scroll the browser with the scrollwheel, you see the highlighted item move up or down by more than 1 or 2 squares away from your mouse location.

Looks like google ran into a similar problem with mouse coords. I don't think this should hold up turning on for alpha this week though.

version 3 seems to be working fine.

(In reply to comment #1) > If I move over squares up and down, it looks relative to 1 square distance. If > I do that and then scroll the browser with the scrollwheel, you see the > highlighted item move up or down by more than 1 or 2 squares away from your > mouse location. I should have said, if I hover over a square then move the scrollwheel at least two times (2*6) *but do not move the mouse*, the hovered square doesn't follow the mouse coordinates and you should see the hovered item is now about 1-3 squares away from your mouse location. (In reply to comment #3) > version 3 seems to be working fine. I'm on Silverlight 3.0 and it doesn't WFM.

(In reply to comment #4) > (In reply to comment #1) > > If I move over squares up and down, it looks relative to 1 square distance. If > > I do that and then scroll the browser with the scrollwheel, you see the > > highlighted item move up or down by more than 1 or 2 squares away from your > > mouse location. > > I should have said, if I hover over a square then move the scrollwheel at least > two times (2*6) *but do not move the mouse*, the hovered square doesn't follow > the mouse coordinates and you should see the hovered item is now about 1-3 > squares away from your mouse location. That is if you move your mouse again.. its still 2-3 squares away after scrolling the mousewheel first unless your scroll location is in line with the browser and mouse. And to reproduce, there should be scrollbars in the window with the ability to scroll up and down.

Confirmed the bug exist for both Silverlight 3 (3.0.50106.0) and 4 (4.0.41108.0). The degree of offset is relative to scroll position of the page. If the applet is vertically centered on the page, the coordinates line up. If the applet is not centered, the offset is relative to the scroll offset from center.

fixed a couple comment nits.

fixed header spacing. (Bent, the changes in PluginInstanceChild::WinlessHandleEvent are at the top. The rest is just touched up indentation on the lower code.)

Comment on attachment 428822 [details] [diff] [review] fix Looks good!

Intresting. Using the latest hourly, the pointer is now correct. What's strange, and I doubt its related to this patch, is that with OOPP 'off', the pointer is again skewed, but I think its been this way now that I think about it. Another item of note, and likely needs another bug, is that once you select an item from the showcase the 'view' and 'close x' are not click-able, either with OOPP on or off.. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100224 Minefield/3.7a2pre Firefox/3.6 ID:20100224165745

While in IE8 the button will 'highlight', clicking has no action.. must be a site problem.

With OOPP off the pointer is skewed really bad. With it on it is still skewed but not as much. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100224 Minefield/3.7a2pre Firefox/3.6 - Build ID: 20100224165745

(In reply to comment #13) > While in IE8 the button will 'highlight', clicking has no action.. must be a > site problem. WFM; but I'm on XP + Silverlight 4. You're using Win7, so who knows.

Something is seriously wrong. It's beginning to look like the bug may be with Silverlight or .NET itself. Prior to uninstalling Silverlight 4 and installing 3, to verify that the bug existent with 3 also, then reinstalling 4, I could verify that the bug did not appear with IPC plugins disabled. Now I get the bug regardless, including with the patch. There's something random and inconsistent going on and it's looking less like a Firefox problem. This would seem to explain why Jim, Gary, and I are seeing all this weirdness. The patch should therefore be backed out, as it's effectively a placebo. This bug therefore is probably invalid. Not sure how else to proceed with this.

Just checked this against Chrome. Both IE 8 and Chrome render properly for me. So Firefox is the only one that's getting this wrong, and it's not an IPC bug. IE 8: Correct Chrome 5: Correct Minefield: Wrong Opera 10.5: (incomplete: after several minutes of high CPU waiting, terminated it) Will try in the next few days to see if this is a regression. First suspect is bug 526394.

Well this sucks. How come the June 18, 2009 to January 28, 2010 builds are missing from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly ?

Actually June 18, 2009 to January 23, 2010 is what's missing.

Found the regression window: Works: 2009/06/2009-06-26-04-mozilla-central http://hg.mozilla.org/mozilla-central/rev/a55b20529273 Fails: 2009/06/2009-06-27-04-mozilla-central http://hg.mozilla.org/mozilla-central/rev/b8cbe3c9542b http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a55b20529273&tochange=b8cbe3c9542b Could this be a regression from Bug 500672?

Sorry. Didn't see someone changed it. But this should not be resolved fixed. Nor should it be Core::IPC

If you want to keep this as fixed, I guess I'll have to open a new bug.

Restored original title.

Okay then. Filed Bug 548557, targeting the actual regression, since this bug doesn't fix the issue.

Not until it's confirmed this is in fact a regression in fx proper. FWIW, ipc disabled, m-c nightly, silverlight 3, the coordinates are fine on various silverlight test cases here. ipc enabled, nightly from yesterday, mouse coords are off. patch applied, ipc enabled, mouse coords are back to normal. Please test on something other than that silverlight.net showcase page before making assumptions as to what's going on here. The showcase page has a number of issues, any number of which might be interfering with results. Try - http://www.e-naxos.com/slsamples/lorem/loremgen.html or any of the other test apps on silverlight.net. Also, the main banner on silverlight.net is useful, since you can select different showcase apps from there.

(also, when testing, please make sure you're dealing with a windowless control.) I'm looking for good test apps this morning, will post what I find in a bit.

Issue is resolved - clearing old keywords - qa-wanted clean-up