438276 - Chrome/UI (context menu) disables :hover

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Biju]

Attachment: ooo_login.png

This is an issue I see at OOo, probably it may appear at other sites also.
Mouse events are firing too fast for http://www.openoffice.org/
At current state it is only a cosmetic issue.

I dont know to suggest an alternative behavior.
But I wish there is a better experiences for users.

Here is what I see....

Case 1
------
 1. type your email id on a notepad
 2. copy it to clipboard
 3. goto http://www.openoffice.org/ in firefox
 4. on top right you see box for
    * Search
    * Change Language
    * Log In
 5. Move mouse over "Log In"
 6. username/password box shown
 7. right click on username box
 8. context menu shown
 9. move mouse over context menu 

Result:
"Log In" disappeared and "Search" tab shown


Case 2
------
 1. goto http://www.openoffice.org/
 2. on top right you see box for
    * Search
    * Change Language
    * Log In
 3. Move mouse over "Log In"
 4. enter username/password and allow form save
 5. go to http://www.openoffice.org/ again
 6. Move mouse over "Log In"
 7. go to username box
 8. pull down form fill menu
 9. move mouse over form fill menu

Result:
"Log In" disappeared and "Search" tab shown as in attachment ooo_login.png

I can select form fill item and it goes correctly to the username box. So the functionality is not really lost, but just a cosmetic issue.
Also in Case 1 pasting by selecting paste from context menu will also work

Comment 1

[Mike Young]

I see this too on Linux/FF3.

The problem is that the UI elements (context menu, and saved form information) cause the ":hover" state to be lost.

When you move your mouse over the context menu, the page no longer registers you "hovering" over the login tab. This happens on any page using the CSS :hover.

I thought with 4 hundred thousand bugs out there, this would have to be a dupe, but I couldn't find one.

You can reproduce this issue right on this bugzilla page: 
1) Hover over any link and notice that the color changes to grey. 
2) Right click on that link 
3) Move your mouse anywhere off the link (or even to the menu that covers the link). The color of the link changes back to its un-hovered value.

Parts of the UI exhibit this behavior as well. (Right click the Home button)
But other parts do not. (Right click a bookmark in the Bookmarks menu)


I would argue that the bookmark's menu behavior is correct for all cases. A Right Click context menu (And any chrome-created menu like the saved form info menu) should not grab focus/hover away from the page itself. The page designer has no control over these chrome items and cannot be expected to code for their existence in CSS.

Additionally, a Context menu acts specifically upon the item for which it is clicked. To have that item disappear (in the case at OOo) and yet still be acted upon by the menu is disconcerting to say the least.

I see two potential solutions:
1) "Freeze" the page state when a context menu or piece of chrome appears.
2) Treat the context menu and other chrome as children of the items to which they relate.

I'd lean towards #2 since both of the issues discussed here are specifically related to the page-items involved. A context menu applies to the item which is clicked; a form-fill menu applies to that form. If we treated them as children, that would keep the element focused/hovered for the purposes of CSS. 
We'd need to watch out for the other CSS properties though. Boxes that resize to contain their children shouldn't encompass the context menu for example.

Moving to trivial since this does cause more hassle than "enhancement". I think we need a UI/CSS Spec expert to look at this to provide a better answer from a usability perspective.

Comment 2

[Biju]

(In reply to comment #1)
> You can reproduce this issue right on this bugzilla page: 
> 1) Hover over any link and notice that the color changes to grey. 
> 2) Right click on that link 
> 3) Move your mouse anywhere off the link (or even to the menu that covers the
> link). The color of the link changes back to its un-hovered value.

Just tested in IE6 and found when you right click on a link and move the mouse over context menu, this issue wont happen.

Comment 3

[Mike Young]

I did a few other tests of browsers like konqueror and IE as well.
It seems they appear to go the route of option #1: Freeze the page when a context menu is raised.

Having played around with it, I think i like that option better after all. It seems consistant with how other events are handled (like clicking... when a menu is open, a click on the page dismisses the menu, it doesn't take action on the page.)

Hover should fit into that same category. when UI elements are active, the hover state of the page should freeze.

Comment 4

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)