363777 - hover dynamic after Rightclick/saveAs, part 2

Status: VERIFIED WORKSFORME

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

Description

[Martijn Wargers (dead)]

This has almost the same steps to reproduce as bug 306149:
- Right-click a link and click on 'Save Link As...'
- Click on 'Cancel' in the file picker dialog
- Right-click again on the same link

Result:
The mouse shows the same strange behavior again as mentioned in bug 306149, where the mouse pointer doesn't really change (only very shortly) into a hand cursor, when over a link.

Comment 1

[Martijn Wargers (dead)]

Ah, you don't need to click on the 'Save Link As...', a click on the 'Copy Link Location' triggers the same bug.

Comment 2

[Ere Maijala (slow)]

We seem to actually have two root view managers, one for chrome and one for content. After the context menu has been displayed once, chrome root vm remembers the cursor position where the menu entry was clicked. When the menu is brought up again, the view managers fight to find the correct mouse position:

** nsViewManager 040CFA80: mouse move at (67, 162) (root=040CFA80, real=yes)
** nsViewManager 040CFA80: RootViewManager 040CFA80 mMouseLocation set to (67, 162)
** nsViewManager 02C31A78: synthesizing mouse move at (134, 388)
** nsViewManager 02C31A78: mouse move at (59, 110) (root=02C31A78, real=no)

Only the real mouse move coordinates (along with the inactive root vm) change. If mouse is brought to the context menu and then back to the link, everything's back to normal as root vm coordinates are reset. Root vm could be reset by adding |RootViewManager()->mMouseLocation = nsPoint(NSCOORD_NONE, NSCOORD_NONE);| to |case NS_DESTROY:| in nsViewManager::DispatchEvent, but shouldn't we rather have a single root view manager? roc?

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Bug 130078 is about unifying the view manager hierarchies so we have a single root view manager. That change should fix this bug.

Comment 4

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

It works for me now. Can you confirm?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008060906 Minefield/3.0pre

Comment 5

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Resolving as WFM. Feel free to reopen this bug if it rehappens to you again.

Comment 6

[chAlx]

Works for me too in some versions.

Ere Maijala gave a detailed review for the internal behavior; following is more user-side review to check the reproducibility.

Steps (tested on this bug page):

 - Right-click any link
 - Move the mouse pointer over right-click menu, removing it from the link
 - While the pointer is over menu, cancel it (Esc) -- mouse pointer should be in the document text area (neither link nor chrome)
 - Move mouse pointer back to the same link and right-click again
 - While right-click menu is open (don't hover it!) move the mouse pointer over any link: cursor should blink switching between arrow and hand icons.

Work-around: right-clicking any link, move mouse cursor over right-click menu and move it back over the link.

WORKS with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9, Modern theme

WORKS with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16

WORKS with Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

DOESN'T WORK with Mozilla/5.0 (Windows; U; Windows NT 5.2; ru-RU; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

DOESN'T WORK with Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

DOESN'T WORK with Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.8.1.14) Gecko/20080416 Fedora/2.0.0.14-1.fc7 Firefox/2.0.0.14