356528 - XUL menu only hilights items on mouseover the first time opened

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Josh Aas]

To reproduce:

1. Open Cocoa Firefox
2. Click on a live bookmark in the bookmark bar
3. Mouse over menu items, notice that they hilite when the mouse is over them
4. Close the menu
5. Click on the same live bookmark in the bookmark bar, notice that menu items do not hilite on mouseover

Comment 1

[Josh Aas]

Attachment: cleanup v1.0

When I was looking at our child view event handling code I found some of it to be strangely written, unclear, and inefficient. This patch doesn't change any behavior at all, but it reorganizes the code in a more clear and understandable way and removes some redundant checks.

Comment 2

[Mark Mentovai]

Comment on attachment 242155 [details] [diff] [review]
cleanup v1.0

cleanup ok

Comment 3

[Josh Aas]

cleanup checked in

Comment 4

[monkeypox37]

Is this a dupe of #324963 or just something similar?

Comment 5

[Josh Aas]

This is not a dupe of bug 324963.

Comment 6

[Josh Aas]

I have figured out exactly what is going but I haven't found a fix yet.

The problem is that when you open a menu like a live bookmark the second time through, all of the mouse move events that get generated when you mouse over it are getting sent to the view in the window underneath it. Like the mouse move is going *through* the menu window. The result is that the mouse move events aren't targetting the view in the menu and getting forwarded to the menu's window object. Why this happens only the second time you open the menu and not the first I don't know.

Comment 7

[monkeypox37]

>This is not a dupe of bug 324963.
>
>The problem is that when you open a menu like a live bookmark the second time
>through, all of the mouse move events that get generated when you mouse over it
>are getting sent to the view in the window underneath it.

That sounds like what is happening with 324963 IMO. The triggering mechanism might be different (so it not being an exact dupe) but the description people are having make it sound like the same underlying problem (see comment 7, etc. of that bug for example - https://bugzilla.mozilla.org/show_bug.cgi?id=324963#c7}.

I don't have any live bookmarks but do see this all the time with regular folders on the bookmark bar. No idea why it happens either but having a sub-folder pop up (and then never close which is another bug) will cause it to happen every time.

Comment 8

[Håkan Waara]

Attachment: Fix

That was fun. Because of all our popup window trouble, I wrote a test app where I recreated how our popupmenus work, and thus ran into this bug.

It turns out it's very important to turn of mousemoved messages when you hide (orderOut:) a window. If you don't, it will actually still get these messages after it's hidden!

And when you show it again, other windows' tracking rects will be in the way, so all hell will break loose.

The reason it didn't happen for contextmenus, is because those windows are always recreated from scratch. If that is a bug, let's file it as a spin-off.

Comment 9

[Håkan Waara]

Hm, I think I'll need to turn on/off mouseMoved messages for sheets too. Just need to find the right places to hook in.

Comment 10

[Håkan Waara]

Attachment: Fix v2

This one includes sheets. I tested with the "Add bookmarks" sheet, and it now changes its cursor to caret when I move over the textfield (it didn't with the previous patch).

I'm basically just pairing every call to show/hide a window (in nsCocoaWindow::Show()) to turning on/off mousemoved messages.

Comment 11

[Josh Aas]

Comment on attachment 245561 [details] [diff] [review]
Fix v2

You have sr from pav, he just doesn't have his laptop here to mark it himself.

Comment 12

[Håkan Waara]

Checked in.

Comment 13

[Boris Zbarsky [:bzbarsky]]

This appears to have caused bug 371405.