Unexpected Mouse Coordinate Return when MouseEnter or MouseExit Event Fired

RESOLVED FIXED in mozilla27

Status

()

Core
Plug-ins
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: stone.zhao, Assigned: smichaud)

Tracking

23 Branch
mozilla27
x86_64
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 806504 [details]
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
(Reporter)

Updated

5 years ago
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)
(Assignee)

Comment 4

5 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(smichaud)
(Assignee)

Updated

5 years ago
Priority: P3 → --
(Assignee)

Comment 5

5 years ago
>> 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.
(Assignee)

Comment 6

5 years ago
> 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.
(Reporter)

Comment 7

5 years ago
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:
http://nightly.mozilla.org/
(Reporter)

Comment 9

5 years ago
Hi Steven, I downloaded the nightly build today, the version is 27.0a1. I verified it and the bug still can reproduce.
Created attachment 811201 [details] [diff] [review]
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/smichaud@pobox.com-d3cea230d82b/try-macosx64/firefox-27.0a1.en-US.mac.dmg

Please try it out and let us know your results.
Assignee: nobody → smichaud
(Reporter)

Comment 11

5 years ago
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+
https://hg.mozilla.org/mozilla-central/rev/f12083ad5943
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
You need to log in before you can comment on or make changes to this bug.