Tooltips cause bogus mouse events

RESOLVED FIXED in mozilla1.9.3a1

Status

()

P2
normal
RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: kenfeldman, Assigned: mstange)

Tracking

Trunk
mozilla1.9.3a1
All
Mac OS X
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.1 +
wanted1.9.0.x -
in-testsuite +

Firefox Tracking Flags

(status1.9.2 beta4-fixed)

Details

(URL)

Attachments

(1 attachment, 5 obsolete attachments)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0

Summary: HTML links with title attributes lose focus if cursor moves even the slightest bit while the title box is displayed. This causes CSS dropdown menus to collapse. This bug does not happen on the first attempt after launch or restart, but does happen every time afterwards.

The title attribute should pop up when you hover/pause on a link (kind of like a tooltip). This happens correctly. but if you move or wiggle the cursor while the title is showing, then the link loses focus, and the menu collapses.

This affects the hover state of CSS links, and since CSS dropdown menus rely on that, they'll collapse when the focus is lost.

Reproducible: Always

Steps to Reproduce:
(Won't occur on the first try after launch or re-launch, but will occur every time afterwards.)
1. Hover/pause on a link that has a title attribute
2. Wait for title to appear
3. Slightly move or wiggle the cursor while the title is showing, then the link loses focus, and the menu collapses. This affects the hover state of CSS links, and since CSS dropdown menus rely on that, they'll collapse when the focus is lost.
Actual Results:  
HTML links with title attributes lose focus if cursor moves even the slightest bit while the title box is displayed. This causes CSS dropdown menus to collapse. This bug does not happen on the first attempt after launch or restart, but does happen every time afterwards.


Expected Results:  
The title attribute should pop up when you hover/pause on a link (kind of like a tooltip). This happens correctly. but if you move or wiggle the cursor while the title is showing, then the link loses focus, and the menu collapses.

Cursor should be able to be moved so that user can navigate dropdown menus. For single links, the link should remain active as long as cursor is hovering.

This affects the hover state of CSS links, and since CSS dropdown menus rely on that, they'll collapse when the focus is lost.
(Reporter)

Updated

10 years ago
Version: unspecified → 3.0 Branch

Comment 1

10 years ago
I can confirm this, try it on:
http://dev.datenkind.de/ff3/ff3-tooltip-bug.html

This has to be fixed immediately!


greetings
(Reporter)

Comment 2

10 years ago
Yup. Here's my example too: http://www.kpfdigital.com/firefoxbug/
(Reporter)

Comment 3

10 years ago
But it doesn't happen on the first attempt after FF is started/restarted. Only happens on the second time forward.
I've confirmed this in Firefox 3.

I also see it in current Camino 1.9.0-branch nightlies and Camino
1.6.1 (a 1.8-branch release).  So this must be a Cocoa widgets bug.

Camino generally uses native widgets (for objects like tooltips and
link-titles).  Firefox never does (all its widgets are customized).
Stuart, do you know if Camino uses native tooltips for link-titles?

In any case, the bug seems to be that link-titles are treated exactly
like tooltips, and are dismissed too "early".
Assignee: nobody → joshmoz
Component: General → Widget: Cocoa
Product: Firefox → Core
QA Contact: general → cocoa
Version: 3.0 Branch → unspecified
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: joshmoz → smichaud
Priority: -- → P2
Summary: but does happen every t HTML links with title attributes lose focus if cursor moves even the slightest bit while the title box is displayed. This causes CSS dropdown menus to collapse. This bug does not happen on the first attempt after launch or restart → HTML link titles are treated like tooltips, and dismissed "too early"
Flags: wanted1.9.1?
Flags: wanted1.9.0.x?

Comment 5

10 years ago
Camino never uses actual tooltips, just an NSWindow of our own creation and positioning.

However, I'm unable to reproduce this in Camino 1.6 or a current Camino nightly on two different machines, and one of the test cases explicitly says it doesn't happen in Camino 1.5. Your shortened version of the summary is not what the bug description is actually about, so I suspect that what you reproduced in Camino is not this bug at all; it sounds like you are talking about the tooltip being dismissed (which I'm not sure is even a bug), not the entire menu collapsing.
(Reporter)

Comment 6

10 years ago
Here's one more observation: While I previously reported that restarting FF3 prevents the bug from happening the FIRST time it's tried, I have just found that merely closing the open window, and then opening a new window will also prevent the bug on the first attempt. This occurs even if there was another FF3 window open first. (Observed this while writing this reply in one window, and trying bug in a second window.)

Note that opening a new tab does not reset the first-try-only success.
(In reply to comment #5)

> Camino never uses actual tooltips, just an NSWindow of our own
> creation and positioning.

Thanks for the info.

> However, I'm unable to reproduce this in Camino 1.6 or a current
> Camino nightly

> it sounds like you are talking about the tooltip being dismissed
> (which I'm not sure is even a bug), not the entire menu collapsing

Sorry, you're right.

In FF3 I see both the link-title being dismissed early and the menu
collapsing.  In Camino (1.6.1 and 1.9.0-branch nightlies) I see only
the link-title being dismissed early.

Both may be bugs, but I think the menu collapsing is the more serious
issue.  So that's what I'll put in the summary.
Summary: HTML link titles are treated like tooltips, and dismissed "too early" → HTML links with titles lose focus on moving mouse, causing CSS dropdown menus to collapse
Not wanted for 1.9.0.x. Let's get this in 1.9.1.
Flags: wanted1.9.0.x? → wanted1.9.0.x-

Updated

10 years ago
Flags: wanted1.9.1? → wanted1.9.1+
(Assignee)

Comment 9

10 years ago
I'm digging into this. I believe bug 450325, bug 461589 and bug 465522 and this bug have the same underlying problem.

And the problem is that the mousemove event that hides the tooltip has the wrong position. Interestingly, the difference between the wrong position and the actual position is exactly the same as the window's position on the screen.

Now I just need to find out where the incorrect screen-to-window translation is happening.
Assignee: smichaud → mstange
Status: NEW → ASSIGNED
(Assignee)

Comment 10

10 years ago
Created attachment 351270 [details] [diff] [review]
v1

This patch fixes all the bugs I mentioned in the previous comment.

My debugging printfs showed that the first mouse move event after the tooltip is shown is sent twice:
 - first to the NSView in the tooltip window (which is the wrong target for
   this event), and
 - second to the NSView of the window where the mouse is actually over.

Additionally, the coordinates that the second event returns from [theEvent locationInWindow] are wrong (off by the window's position on the screen).

Since the first event is sent to the wrong window, [[mWindow contentView] hitTest:...] returns nil. So we assume that the mouse isn't over any window (which is wrong) and send a mouse exit event with coordinates relative to the tooltip (also wrong).

---

My patch changes ensureCorrectMouseEventTarget: to check for the right window even if no rollup widget is visible. This makes us ignore the first event.

And for some reason it also causes the second event to have sane coordinates, and thus fixes this bug.
Attachment #351270 - Flags: review?(smichaud)
(Assignee)

Comment 11

10 years ago
Created attachment 351275 [details] [diff] [review]
v2

I just tested the patch on 10.4 and noticed that the "second event" isn't sent there. So we do need to resend the event. This will result in sending the same mouse move event twice on 10.5 but I don't think that will break anything.
Attachment #351270 - Attachment is obsolete: true
Attachment #351270 - Flags: review?(smichaud)
(Assignee)

Updated

10 years ago
Attachment #351275 - Flags: review?(smichaud)
(Assignee)

Updated

10 years ago
Attachment #351275 - Attachment is obsolete: true
Attachment #351275 - Flags: review?(smichaud)
(Assignee)

Comment 12

10 years ago
Comment on attachment 351275 [details] [diff] [review]
v2

This patch breaks mouse capturing when the mouse is held down.
(Assignee)

Comment 13

10 years ago
Furthermore, it makes bug 425556 occur even when no context menu is open.
(Assignee)

Comment 14

10 years ago
Created attachment 351434 [details] [diff] [review]
v3

This patch doesn't have the disadvantages of the previous one and additionally fixes bug 425556.

The algorithm that determines whether a window should receive mouse move events is a little different than that in your patch for bug 425556 because it also works for panels and sheets.

I tested this patch on both 10.5 and 10.4 and couldn't find any regressions.
Attachment #351434 - Flags: review?(smichaud)
(Assignee)

Comment 15

10 years ago
There's one thing that I should clarify.

As far as I can tell, the incorrect mouse position translation I mentioned in comment 9 doesn't happen in Gecko code. It rather looks like it's an Apple bug - the event that's passed to [ChildView mouseMoved:] just carries a bogus location ([event locationInWindow] is wrong). In this patch I'm working around that bug by getting the mouse location from [NSEvent mouseLocation] instead of looking at the event:

 NSPoint nsCocoaUtils::ScreenLocationForEvent(NSEvent* anEvent)
 {
   NS_OBJC_BEGIN_TRY_ABORT_BLOCK_RETURN;
 
+  // Don't trust mouse locations of mouse move events, see bug 443178.
+  if ([anEvent type] == NSMouseMoved)
+    return [NSEvent mouseLocation];
+
   return [[anEvent window] convertBaseToScreen:[anEvent locationInWindow]];
(Assignee)

Comment 16

10 years ago
I've noticed one problem with the patch: When I have two Firefox windows open, start dragging a scrollbar in one of the windows and move the mouse over the other window (while still dragging), the mouse events aren't captured by the active window but instead routed to the window under the mouse (so the scrollbar doesn't move).
So I probably have to add an NSLeftMouseDragged somewhere where I check for NSMouseMoved.

Updated

10 years ago
Blocks: 425556
(Assignee)

Comment 17

10 years ago
Created attachment 360972 [details] [diff] [review]
v4

I've extended the "window accepts mouse event" check to cover all mouse events except NSRightMouseDown, not only mouse move events. This seems to work very reliably.
Attachment #351434 - Attachment is obsolete: true
Attachment #360972 - Flags: review?(smichaud)
Attachment #351434 - Flags: review?(smichaud)
(Assignee)

Comment 18

10 years ago
(Adding dependencies for all the bugs that this patch fixes)
Blocks: 450325, 461589, 465522
Summary: HTML links with titles lose focus on moving mouse, causing CSS dropdown menus to collapse → Tooltips cause bogus mouse events
(Assignee)

Updated

10 years ago
Duplicate of this bug: 486674
(Assignee)

Updated

10 years ago
Duplicate of this bug: 485423
(Assignee)

Updated

9 years ago
Duplicate of this bug: 490914
(Assignee)

Updated

9 years ago
Duplicate of this bug: 491997

Comment 23

9 years ago
Is there an estimated timeframe when can we expect to see the patch to fix this bug implemented in Firefox?
I'd really like to get (back) to this soon ... but I've got a lot of
other things on my plate.

When I do get back to it, I expect I'll want to rewrite Markus' patch,
and that will take at least several days.

So I can't really give an estimate, but it's definitely on my radar.

Comment 25

9 years ago
Thanks for keeping this bug in mind. :)

I'm much less worried about it now that I realize its just effecting the 1%-2% Mac OS X visitors who come to my site, but I still want my popup menus to work for all Firefox users, no matter what their platform is.
(Assignee)

Comment 26

9 years ago
(In reply to comment #24)
> When I do get back to it, I expect I'll want to rewrite Markus' patch,

Does that mean you already have a general opinion of the patch? Could you tell me what you'd like to change?
At this point it's little more than a feeling that I really need to
spend several days looking through this bug's issues.

Sorry :-(

Comment 28

9 years ago
Markus - if you can update this patch and make sure it passes all tests I'll do the review.
Hardware: PowerPC → All
Version: unspecified → Trunk
(Assignee)

Comment 29

9 years ago
Created attachment 394749 [details] [diff] [review]
v4.1

Unfortunately I can't test whether this fixes bug 504450 comment 20 because I can't reproduce it on 10.4.
Attachment #360972 - Attachment is obsolete: true
Attachment #394749 - Flags: review?(joshmoz)
Attachment #360972 - Flags: review?(smichaud)
(In reply to comment #29)
> Created an attachment (id=394749) [details]
> v4.1
> 
> Unfortunately I can't test whether this fixes bug 504450 comment 20 because I
> can't reproduce it on 10.4.

I can try a tryserver build for you.
(Assignee)

Comment 31

9 years ago
Created attachment 394755 [details] [diff] [review]
v4.2

updated for bug 510428
Attachment #394749 - Attachment is obsolete: true
Attachment #394755 - Flags: review?(joshmoz)
Attachment #394749 - Flags: review?(joshmoz)
(Assignee)

Comment 32

9 years ago
Tryserver build: https://build.mozilla.org/tryserver-builds/mstange@themasta.com-try-97bf8ff6b255/try-97bf8ff6b255-macosx.dmg

It's completely green, but given that native mouse events aren't tested at all, this doesn't mean much.

Updated

9 years ago
Attachment #394755 - Flags: review?(joshmoz) → review+
The tryserver build *doesn't* fix the focus issue mentioned in comment 29 (http://www.coteindustries.com/articles/html_articles/tabindex.html) on Mac OS X 10.5.8
(Assignee)

Updated

9 years ago
Duplicate of this bug: 511327
(Assignee)

Comment 35

9 years ago
http://hg.mozilla.org/mozilla-central/rev/ef935f692eb2
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
(Assignee)

Updated

9 years ago
Duplicate of this bug: 461589
(Assignee)

Updated

9 years ago
Duplicate of this bug: 490377
(Assignee)

Updated

9 years ago
Attachment #394755 - Flags: approval1.9.2?
(Assignee)

Comment 38

9 years ago
Comment on attachment 394755 [details] [diff] [review]
v4.2

Requesting approval1.9.2 - this bug has caused web developers a lot of pain, see all the duplicates. The patch has baked for over a month and no regressions were reported. Bug 470845 has added tests for this bug.
(Assignee)

Updated

9 years ago
Flags: in-testsuite+
Comment on attachment 394755 [details] [diff] [review]
v4.2

a192=beltzner as long as it goes in with the tests from bug 470845
Attachment #394755 - Flags: approval1.9.2? → approval1.9.2+
(Assignee)

Updated

9 years ago
Depends on: 541904
You need to log in before you can comment on or make changes to this bug.