Closed Bug 917702 Opened 9 years ago Closed 9 years ago

Unexpected Mouse Coordinate Return when MouseEnter or MouseExit Event Fired


(Core Graveyard :: Plug-ins, defect)

23 Branch
Not set


(Not tracked)



(Reporter: surfzsl, Assigned: smichaud)



(2 files)

Attached file 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( has been defined the init value for these event:
  if (!mGeckoChild)

  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(

  // 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) {
      cocoaEvent.type = ((msg == NS_MOUSE_ENTER) ? NPCocoaEventMouseEntered : NPCocoaEventMouseExited); = [aEvent modifierFlags]; = 5; = 5; = [aEvent buttonNumber]; = [aEvent deltaX]; = [aEvent deltaY]; = [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
Severity: normal → major
OS: Windows 7 → Mac OS X
Priority: -- → P3
Unhiding; not a security-sensitive bug.
Group: core-security
Component: Untriaged → Plug-ins
Product: Firefox → Core
Possibly related to bug 909678.
Steven, could this already be fixed by bug 909678?
Severity: major → normal
Flags: needinfo?(smichaud)
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.
Ever confirmed: true
Flags: needinfo?(smichaud)
Priority: P3 → --
>> 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.
> 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.
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.
Nightly builds can be found here:
Hi Steven, I downloaded the nightly build today, the version is 27.0a1. I verified it and the bug still can reproduce.
Attached patch Possible fixSplinter Review
Here's a possible fix.

And here's a tryserver build made from it:

Please try it out and let us know your results.
Assignee: nobody → smichaud
Hi Steven, thank you very much! I've verified it, it can't reproduce now, and works fine.
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.
Attachment #811201 - Flags: review?(spohl.mozilla.bugs)
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.
Attachment #811201 - Flags: review?(spohl.mozilla.bugs) → review+
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.