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)

1.9.2 Branch
All
macOS
defect
Not set
normal

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)

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
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.
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.
This is probably a regression from bug 496601.
Assignee: nobody → mstange
Blocks: 496601
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: regression
Attached patch v1Splinter Review
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)
This probably shouldn't block, but let's fix it.
Whiteboard: [should not block]
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+
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Version: unspecified → 1.9.2 Branch
Attachment #416440 - Flags: approval1.9.2?
I really think we should take this for 3.6.
Attachment #416440 - Flags: approval1.9.2? → approval1.9.2+
Comment on attachment 416440 [details] [diff] [review] v1 a192=beltzner, this lands ASAP
Depends on: 548214
No longer depends on: 548214
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: