Closed Bug 362635 Opened 18 years ago Closed 8 years ago

When the tooltip is displayed with mouse over of the link, the mouse pointer is fixed.

Categories

(Core :: General, defect)

PowerPC
macOS
defect
Not set
minor

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: sugar.waffle, Unassigned)

References

()

Details

(Keywords: regression, testcase)

Attachments

(1 file)

In Firefox2.0 release, there is no problem. 
When the tool chip is displayed with mouse over to the link to which the tool chip is set, the mouse pointer is not changed. 

This problem recovers when the place that doesn't include the link etc. is clicked once. 

Reproducible: Always

STR
1. Open URL
2. The mouse is moved to an arbitrary left navigation
3. It waits as it is until the tool chip is displayed
4. The mouse is moved

Actual Results:
The mouse pointer is not changed according to contents. 

Expected Results:
The mouse pointer is correctly changed. 

Mac OS X 10.3.9
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061202 Minefield/3.0a1
So you're saying that the mouse pointer does not change from a normal pointer into a hand?
Keywords: regression
Summary: When the tool chip is displayed with mouse over of the link, the mouse pointer is fixed. → When the tooltip is displayed with mouse over of the link, the mouse pointer is fixed.
(In reply to comment #1)
> So you're saying that the mouse pointer does not change from a normal pointer
> into a hand?
> 

Even if the mouse pointer is moved to places other than the link once, it is a 
hand. 
WFM: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061212 Minefield/3.0a1
works for me on windows with Firefox 3.0a1 ID:2006120408 on Windows XP x64. Tested with the URL provided and the testcase in comment #3
Keywords: testcase
(In reply to comment #3)
> Created an attachment (id=248555) [edit]
> HTML page containing links with tooltips
> 

It reproduces by this test case. 
When the mouse is moved to the link to which a cross cursor is displayed, and the tool chip is displayed, it fixes with a cross cursor. 

It might be a problem that occurs by the movement to Cocoa + Cairo. 

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061213 Minefield/3.0a1
I am able to reproduce this on trunk Build identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a2pre) Gecko/2006121904 Minefield/3.0a2pre

Mouse away from the 2nd or 3rd link after the Tooltip appears and the pointer doesn't return to an arrow.  The pointer will change back to an arrow if you hover outside of the test page content (over the toolbars), but it's stuck there. Hovering over a link again does nothing. It remains this way until focus is set on another tab/window

Status: UNCONFIRMED → NEW
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → general
dupe of bug 366815?
I am able to reproduce this on: 
Mac OSX 10.5.8 Intel as, this bug was originally reported for PPC platform
 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; it; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

How:
1- Open www.mozilla.org
2- Place the mouse on mozilla.org logo on header
3- Wait until the tooltip appears (Back to homepage)
4- Move the mouse slowly for some pixels until the tooltip disappears

Actual Results:
The mouse icon is pointer

Expected Results:
The mouse should be a hand because we are over an <a href> tag

Additional Information:
I also noticed the same issue when moving from a <object> or <embed> to <a>
the mouse wont become hand, but pointer
I *can't* reproduce this bug on 

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091015 Minefield/3.7a1pre
This bug has been tagged for regression and/or closure.

I have confirmed mouse changes as expected in Nightly and latest Release.
Version 	49.0a1
Build ID 	20160517030211
Mac OS X 10.11 & Windows 10
46.0.1
20160502172042
Considering this I will mark this as Resolved-WFM
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: