917702 - Unexpected Mouse Coordinate Return when MouseEnter or MouseExit Event Fired

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[stone.zhao]

Attachment: TestMouseMove4.5.fxp

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36

Steps to reproduce:

1. import the attached file by FlashBuilder
2. Run the project on Mac OSX 10.7 with firefox browser
3. press the mouse button on red block, move the mouse out of the screen, then move back, release the mouse button, it will get 5,5 of the mouse Coordinate

I find the mozilla source code(http://dxr.mozilla.org/mozilla-central/source/widget/cocoa/nsChildView.mm) has been defined the init value for these event:
(void)sendMouseEnterOrExitEvent:(NSEvent*)aEvent
                            enter:(BOOL)aEnter
                             type:(nsMouseEvent::exitType)aType
{
  if (!mGeckoChild)
    return;

  NSPoint windowEventLocation = nsCocoaUtils::EventLocationForWindow(aEvent, [self window]);
  NSPoint localEventLocation = [self convertPoint:windowEventLocation fromView:nil];

  uint32_t msg = aEnter ? NS_MOUSE_ENTER : NS_MOUSE_EXIT;
  nsMouseEvent event(true, msg, mGeckoChild, nsMouseEvent::eReal);
  event.refPoint = LayoutDeviceIntPoint::FromUntyped(
    mGeckoChild->CocoaPointsToDevPixels(localEventLocation));

  // Create event for use by plugins.
  // This is going to our child view so we don't need to look up the destination
  // event type.
  NPCocoaEvent cocoaEvent;
  if (mIsPluginView) {
    if (mPluginEventModel == NPEventModelCocoa) {
      nsCocoaUtils::InitNPCocoaEvent(&cocoaEvent);
      cocoaEvent.type = ((msg == NS_MOUSE_ENTER) ? NPCocoaEventMouseEntered : NPCocoaEventMouseExited);
      cocoaEvent.data.mouse.modifierFlags = [aEvent modifierFlags];
      cocoaEvent.data.mouse.pluginX = 5;
      cocoaEvent.data.mouse.pluginY = 5;
      cocoaEvent.data.mouse.buttonNumber = [aEvent buttonNumber];
      cocoaEvent.data.mouse.deltaX = [aEvent deltaX];
      cocoaEvent.data.mouse.deltaY = [aEvent deltaY];
      cocoaEvent.data.mouse.deltaZ = [aEvent deltaZ];
      event.pluginEvent = &cocoaEvent;
    }
  }



Actual results:

when move the mouse out of firefox browser page, get value 5, 5 of the mouse coordinate 


Expected results:

get the real value of mouse coordinate

Comment 1

[Matt Wobensmith [:mwobensmith][:matt:]]

Unhiding; not a security-sensitive bug.

Comment 2

[Stephen A Pohl [:spohl] (OOO until 5/14)]

Possibly related to bug 909678.

Comment 3

[Georg Fritzsche [:gfritzsche]]

Steven, could this already be fixed by bug 909678?

Comment 4

[Steven Michaud [:smichaud] (Retired)]

This subject came up recently at bug 909678 comment #27 and following.  As you can see there, we don't know why all the Cocoa mouse-entered and mouse-exited events that we send to plugins have their X and Y coordinates set to '5'.  But that code has been in the tree for four years, and this is the first time anyone has complained about it.

This behavior is likely just a bug.  But it's been the same for a long time, and it's possible that plugin vendors have come to "rely" on it -- in the sense that they may have created workarounds for it, which may break if we change our behavior.

That said, I'm more than willing to try changing our behavior (to stop always setting the X and Y coordinates to '5').  But since most plugins are closed-source (and therefore black boxes), we can't know in advance whether nor not this will cause trouble.  So we may end up having to back out this change, several months or even several years down the line.

> Steven, could this already be fixed by bug 909678?

Unfortunately not.

But only a small change would be required to my patch for that bug (currently on the trunk).  I'll post a patch shortly.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

>> Steven, could this already be fixed by bug 909678?
>
> Unfortunately not.

But it *is* possible that our behavior with your testcase has changed.  stone.zhao, please test with tomorrow's (2013-09-19) mozilla-central nightly, when that becomes available.

I suspect that, with my patch for bug 909678, we don't fire a mouse-exit event at all when you drag outside of a plugin, then drag back over it again before releasing the mouse button.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

> I'll post a patch shortly.

I'm going to wait until stone.zhao has had a chance to test with tomorrow's mozilla-central nightly, and we've heard back from him.

Comment 7

[stone.zhao]

Thank you Steven, I received this bug from our QE team, and after my investigation, I found the code in mozilla set these value for coordinate initial value. I also don't know why init it with '5'. Today is Mid-Autumn Day in China, so I am in the holiday, I'll back to work this sunday. 

I don't know how to get the nightly build, you can send me the link, I'll verify it this sunday.

Comment 8

[Georg Fritzsche [:gfritzsche]]

Nightly builds can be found here:
http://nightly.mozilla.org/

Comment 9

[stone.zhao]

Hi Steven, I downloaded the nightly build today, the version is 27.0a1. I verified it and the bug still can reproduce.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

Attachment: Possible fix

Here's a possible fix.

And here's a tryserver build made from it:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-d3cea230d82b/try-macosx64/firefox-27.0a1.en-US.mac.dmg

Please try it out and let us know your results.

Comment 11

[stone.zhao]

Hi Steven, thank you very much! I've verified it, it can't reproduce now, and works fine.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 811201 [details] [diff] [review]
Possible fix

Let's try this for at least a while, and see what happens.

We probably won't know for sure this is safe until it's been in a release for a while, but I think it's very unlikely to cause trouble.

I'm of two minds about just commenting out the offending code (as this patch does), or removing the code (and its comment) altogether.  But I think it's marginally better to leave in the comment -- to remind people that this change might cause trouble in the future.  We can remove them (code and comment) after this change has been in releases for a while without causing trouble.

Comment 13

[Stephen A Pohl [:spohl] (OOO until 5/14)]

Comment on attachment 811201 [details] [diff] [review]
Possible fix

Review of attachment 811201 [details] [diff] [review]:
-----------------------------------------------------------------

I think leaving this in for now is reasonable. Curious to see what the fallout will be, if any.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 811201 [details] [diff] [review]
Possible fix

Landed on mozilla-inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f12083ad5943

Comment 15

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/f12083ad5943