From https://bugs.webkit.org/show_bug.cgi?id=14344#c13 Changing CSS cursor style doesn’t have any effect while the mouse is down.
Note that I'm about to land infrastructure for automated testing of mouse cursor changes in bug 100550. This should make it possible to write layout tests for this scenario.
The reason why cursors are not changed when mouse is down is that changing cursors is done with faking a mousemove event (that's bringing up bug 85343). And because the fake event is not fired while a mouse button is pressed, there will be no cursor change happening. I have fixed that - replaced the use of fake mousemove event with a proper cursor changing logic. I will propose a patch as soon as I have my environment set up correctly to review my own code and hopefully even add some tests.
Proposed a patch on related bug https://bugs.webkit.org/show_bug.cgi?id=85343 that also fixes the bug reported here.
Created attachment 173491 [details] Moved test to the fix in 101857
Comment on attachment 173491 [details] Moved test to the fix in 101857 Attachment 173491 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/14665611 New failing tests: fast/events/mouse-cursor-change.html fast/events/overflow-scroll-fake-mouse-move.html
Comment on attachment 173491 [details] Moved test to the fix in 101857 Attachment 173491 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/14786807 New failing tests: fast/events/mouse-cursor-change.html
Comment on attachment 173491 [details] Moved test to the fix in 101857 View in context: https://bugs.webkit.org/attachment.cgi?id=173491&action=review > LayoutTests/fast/events/mouse-cursor-change.html:40 > + }, 1); Why 1ms here? If we can't guarantee that this works with 0, then it seems like 1ms could still cause flakiness (eg. under load) and we should use a different mechanism instead (such as testing the cursor from inside event handler functions).
(In reply to comment #7) > (From update of attachment 173491 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=173491&action=review > > > LayoutTests/fast/events/mouse-cursor-change.html:40 > > + }, 1); > > Why 1ms here? If we can't guarantee that this works with 0, then it seems like 1ms could still cause flakiness (eg. under load) and we should use a different mechanism instead (such as testing the cursor from inside event handler functions). Tests combined with fix and timeouts set to 0 will come soon in updated patch for Bug 101857.
It’s often incorrect to change the cursor based on what’s under the mouse during a drag. For example, you wouldn’t want to change the cursor from an arrow to a pointing finger just because you were over a link. I don’t know what the CSS specification says about this. I am concerned that this change, despite being worded as a bug fix, could make behavior worse for some common cases. It’s not entirely an implementation quirk that things work this way.
(In reply to comment #9) > It’s often incorrect to change the cursor based on what’s under the mouse during a drag. For example, you wouldn’t want to change the cursor from an arrow to a pointing finger just because you were over a link. I don’t know what the CSS specification says about this. I am concerned that this change, despite being worded as a bug fix, could make behavior worse for some common cases. > > It’s not entirely an implementation quirk that things work this way. Sure, when just dragging around, but when cursor change is initiated by user code code (cursor value changed in style, class changed or something like that) then it isn't it incorrect to not reflect that change?
(In reply to comment #10) > (In reply to comment #9) > > It’s often incorrect to change the cursor based on what’s under the mouse during a drag. For example, you wouldn’t want to change the cursor from an arrow to a pointing finger just because you were over a link. I don’t know what the CSS specification says about this. I am concerned that this change, despite being worded as a bug fix, could make behavior worse for some common cases. > > > > It’s not entirely an implementation quirk that things work this way. > > Sure, when just dragging around, but when cursor change is initiated by user code code (cursor value changed in style, class changed or something like that) then it isn't it incorrect to not reflect that change? Well, if the web page changes style during the drag process, I could imagine one design choice where the cursor changes to match the style where the drag started. Probably not to match the style where the mouse happens to be.
(In reply to comment #11) > Well, if the web page changes style during the drag process, I could imagine one design choice where the cursor changes to match the style where the drag started. Probably not to match the style where the mouse happens to be. There's the drag that's handled by browser and EventHandler doesn't seem to handle those cursors ad all. And then there's the "drag" that is handled by web developer. Usually it involves cancelling the default action on mousedown to disable text selection and drag-and-drop and whatever the browser would do by itself. Then it should be completely developers choice, how the page acts. For example, if it is a drawing app, it might wan't to display a different cursor while user is "draggin" around (drawing, deleting, dragging a selection rectangle, etc.) At the moment it is not possible to change the cursor after user has pressed mouse button down, because cursor change in CSS is going through a fake mousemove event, which, in case there is a mouse button pressed down, is just cancelled. So, WebKit has made a strong design choice and a web developer has, at the moment, no way to work around it. Do you think this is appropriate? (IE and FF allow changing cursor while a mouse button is down). Do web devs really have to use cursor:none and use a positioned div to display the correct cursor for their app?
(In reply to comment #12) > At the moment it is not possible to change the cursor after user has pressed mouse button down Yes, that’s what this bug is about. > Do you think this is appropriate? (IE and FF allow changing cursor while a mouse button is down). > Do web devs really have to use cursor:none and use a positioned div to display the correct cursor for their app? I think you’re overreacting here. We’re trying to decide *what* change to make. I suggested an option where the cursor could indeed be changed. I know you really want this feature to work in WebKit. I want to make sure that when adding it we don’t make existing good behavior worse. It’s possible that both IE and Firefox have some solution to the problem of unwanted cursor changes during drags. Perhaps someone should test them to see.
(In reply to comment #13) > I think you’re overreacting here. We’re trying to decide *what* change to make. I suggested an option where the cursor could indeed be changed. Sorry, I didn't read that out from your comments, maybe the wording wasn't clear. Currently WebKit does update cursor on moving mouse while a button is pressed, but does not if mouse is idle. So, the patch in bug 101857 only changes behavior when mouse button is pressed and mouse not moved. To cause a cursor change under those conditions you can do it by a timer or in mousedown handler. Both cases are not reflected until you move the mouse and there should be no question about if it is a bug or not. And the patch doesn't basically change anything more than bypass the check that disabled updating cursor while button is held down. Regular mousemove didn't have that check but the fake mousemove event used on style changes, does.
Hey good people, what's happening with this bug? Nobody gives it the feels it requires... I came into a situation in dire of needing this fixed :( "Distilled" Bug Demo: http://jsbin.com/geqacibofu/edit?html,css,js,output Thanks for taking the time coming back to this one! hope it's easy to fix..
Very ODD. now it does work. I fiddled with this for 2 days! so odd.