Closed
Bug 533208
Opened 15 years ago
Closed 15 years ago
Hiding cursor with cursor:none gets stuck and doesn't recover immediately
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.9.3a1
Tracking | Status | |
---|---|---|
status1.9.2 | --- | final-fixed |
People
(Reporter: jhuckaby, Assigned: mstange)
References
()
Details
(Keywords: polish, regression, Whiteboard: [should not block][polish-interactive])
Attachments
(1 file)
1.04 KB,
patch
|
jaas
:
review+
beltzner
:
approval1.9.2+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b4) Gecko/20091124 Firefox/3.6b4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b4) Gecko/20091124 Firefox/3.6b4
When you set a CSS "cursor:none" style on a DIV and mouse over it, the cursor disappears as it should. However, when you mouse back OUT, the origin cursor is not immediately restored (the cursor remains hidden). It takes an additional mouse movement or click to see it again.
Firefox 3.5.5 production does this properly.
Reproducible: Always
Steps to Reproduce:
1. Navigate to: http://bowser.macminicolo.net/~jhuckaby/bugs/hidecursor.html
2. Mouse over one of the DIVs, and notice the cursor disappears as it should.
3. Mouse out.
Actual Results:
When you mouse out, the cursor is not restored. It takes an additional click or mouse movement to get it to show.
Expected Results:
When you mouse out, the cursor should immediately reappear.
(In reply to comment #0)
> When you mouse out, the cursor is not restored. It takes an additional click
> or mouse movement to get it to show.
I'm not sure what you mean by "additional mouse movement"? Do you mean that if you're moving the mouse gradually, the cursor becomes correct for the second one-pixel movement outside of the div rather than the first?
(I can't test this now since the only Mac I have access to is via VNC; it sounds like it might be Mac-only.)
Component: Style System (CSS) → Widget: Cocoa
Flags: blocking1.9.2?
QA Contact: style-system → cocoa
Reporter | ||
Comment 2•15 years ago
|
||
Sorry David, its a tough one to explain. Basically, when you mouse out, if you keep the mouse moving (like, in circles), the cursor never reappears. Even if you move it all the way outside the window bounds and onto the menu bar, the cursor still remains completely hidden.
However, if you STOP moving it entirely, then start moving again, the pointer instantly reappears. Or if you click the mouse button, it also reappears. Very odd.
Confirmed that I cannot reproduce on Windows XP Firefox 3.6b4, so its probably Mac-only as you thought. However I am emulating XP on VMWare, so the cursor is, well, "virtualized" :) -- so not a proper test.
Comment 3•15 years ago
|
||
I can sort of reproduce this on OS X with latest Minefield nightly. On Gecko 1.9.1.x and Gecko 1.9.0.x, when moving the mouse downward, the cursor reappears immediately.
With Minefield, moving the mouse slowly downwards then it eventually reappears, but like in slow motion (even if one doesn't stop moving the mouse). With a fast mouse movement, the cursor doesn't reappear until a second mouse move.
Assignee | ||
Comment 4•15 years ago
|
||
This is probably a regression from bug 496601.
Assignee: nobody → mstange
Blocks: 496601
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: regression
Assignee | ||
Comment 5•15 years ago
|
||
Looks like hide/unhide "stacks", so those calls must be balanced.
In the testcase you can see that the more you move your mouse in the cursor:none rect, the more you need to move your mouse outside of it until it reappears.
Attachment #416440 -
Flags: review?(joshmoz)
Comment 6•15 years ago
|
||
This probably shouldn't block, but let's fix it.
Whiteboard: [should not block]
Updated•15 years ago
|
Flags: wanted1.9.2+
Flags: blocking1.9.2?
Flags: blocking1.9.2-
Keywords: polish
Whiteboard: [should not block] → [should not block][polish-interactive]
Attachment #416440 -
Flags: review?(joshmoz) → review+
Assignee | ||
Comment 7•15 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Version: unspecified → 1.9.2 Branch
Assignee | ||
Updated•15 years ago
|
Attachment #416440 -
Flags: approval1.9.2?
I really think we should take this for 3.6.
Updated•15 years ago
|
Attachment #416440 -
Flags: approval1.9.2? → approval1.9.2+
Comment 9•15 years ago
|
||
Comment on attachment 416440 [details] [diff] [review]
v1
a192=beltzner, this lands ASAP
Assignee | ||
Comment 10•15 years ago
|
||
status1.9.2:
--- → final-fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•