hover dynamic after Rightclick/saveAs, part 2

VERIFIED WORKSFORME

Status

()

Core
Event Handling
VERIFIED WORKSFORME
11 years ago
10 years ago

People

(Reporter: Martijn Wargers (dead), Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

Comment 1

11 years ago
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

11 years ago
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?
Bug 130078 is about unifying the view manager hierarchies so we have a single root view manager. That change should fix this bug.
Depends on: 130078
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
Resolving as WFM. Feel free to reopen this bug if it rehappens to you again.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
(Reporter)

Updated

10 years ago
Status: RESOLVED → VERIFIED

Comment 6

10 years ago
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
You need to log in before you can comment on or make changes to this bug.