53341 2011-01-28 15:44:36 -0800 Changing CSS cursor style doesn’t have any effect while the mouse is down. 2018-08-07 04:39:37 -0700 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) PC OS X 10.5 NEW P2 Normal --- 100550 101857 1 simon.fraser webkit-unassigned aivopaas darin dbates dglazkov dpashk rbyers syoichi vepomoc vsync.design webkit.review.bot oldest_to_newest 341811 0 simon.fraser 2011-01-28 15:44:36 -0800 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. 762109 1 rbyers 2012-11-08 13:21:02 -0800 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. 762283 2 aivopaas 2012-11-08 16:08:19 -0800 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. 763021 3 aivopaas 2012-11-09 07:55:01 -0800 Proposed a patch on related bug https://bugs.webkit.org/show_bug.cgi?id=85343 that also fixes the bug reported here. 763798 4 173491 aivopaas 2012-11-11 00:07:45 -0800 Created attachment 173491 Moved test to the fix in 101857 763803 5 173491 buildbot 2012-11-11 00:39:16 -0800 Comment on attachment 173491 Moved test to the fix in 101857 Attachment 173491 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 763835 6 173491 webkit.review.bot 2012-11-11 06:02:27 -0800 Comment on attachment 173491 Moved test to the fix in 101857 Attachment 173491 did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/14786807 New failing tests: fast/events/mouse-cursor-change.html 770278 7 173491 rbyers 2012-11-18 19:12:52 -0800 Comment on attachment 173491 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). 770451 8 aivopaas 2012-11-19 01:06:08 -0800 (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. 834431 9 darin 2013-02-15 15:54:14 -0800 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. 834678 10 aivopaas 2013-02-16 01:27:06 -0800 (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? 834782 11 darin 2013-02-16 12:57:30 -0800 (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. 834804 12 aivopaas 2013-02-16 13:34:48 -0800 (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? 834821 13 darin 2013-02-16 14:03:51 -0800 (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. 834966 14 aivopaas 2013-02-17 01:42:24 -0800 (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. 1369597 15 vsync.design 2017-11-08 14:13:22 -0800 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.. 1369603 16 vsync.design 2017-11-08 14:17:27 -0800 Very ODD. now it does work. I fiddled with this for 2 days! so odd. 173491 2012-11-11 00:07:45 -0800 2012-11-18 19:12:52 -0800 Moved test to the fix in 101857 bug-53341-20121111100542.patch text/plain 4273 aivopaas U3VidmVyc2lvbiBSZXZpc2lvbjogMTM0MTcwCmRpZmYgLS1naXQgYS9MYXlvdXRUZXN0cy9DaGFu Z2VMb2cgYi9MYXlvdXRUZXN0cy9DaGFuZ2VMb2cKaW5kZXggMDQ3YjllMzI5OTRiYTU3M2I3MmFi YmVkYzU4N2NlNzE1ZTY4NzFiZS4uY2RjOTAxNDQwNTM5ZTFjYmVjYzAyYjE5OWRlMmY3ZDAwMTIw ZmUyMyAxMDA2NDQKLS0tIGEvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCisrKyBiL0xheW91dFRlc3Rz L0NoYW5nZUxvZwpAQCAtMSwzICsxLDEzIEBACisyMDEyLTExLTExICBBaXZvIFBhYXMgIDxhaXZv cGFhc0BnbWFpbC5jb20+CisKKyAgICAgICAgQ2hhbmdpbmcgQ1NTIGN1cnNvciBzdHlsZSBkb2Vz buKAmXQgaGF2ZSBhbnkgZWZmZWN0IHdoaWxlIHRoZSBtb3VzZSBpcyBkb3duLgorICAgICAgICBo dHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9NTMzNDEKKworICAgICAgICBS ZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICAqIGZhc3QvZXZlbnRzL21vdXNl LWN1cnNvci1jaGFuZ2UtZXhwZWN0ZWQudHh0OiBBZGRlZC4KKyAgICAgICAgKiBmYXN0L2V2ZW50 cy9tb3VzZS1jdXJzb3ItY2hhbmdlLmh0bWw6IEFkZGVkLgorCiAyMDEyLTExLTEwICBNaWtlIFdl c3QgIDxta3dzdEBjaHJvbWl1bS5vcmc+CiAKICAgICAgICAgV2ViIEluc3BlY3RvcjogTXVsdGlw bGUgJyVjJyBmb3JtYXR0aW5nIG9wdGlvbnMgc2hvdWxkIGFsbCBoYXZlIGVmZmVjdC4KZGlmZiAt LWdpdCBhL0xheW91dFRlc3RzL2Zhc3QvZXZlbnRzL21vdXNlLWN1cnNvci1jaGFuZ2UtZXhwZWN0 ZWQudHh0IGIvTGF5b3V0VGVzdHMvZmFzdC9ldmVudHMvbW91c2UtY3Vyc29yLWNoYW5nZS1leHBl Y3RlZC50eHQKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMC4uNTJiMTQwNjk0ZjNlNzAxMDI3MmZjNDBkMTIzMDI3MDU5YTFk YzJmZQotLS0gL2Rldi9udWxsCisrKyBiL0xheW91dFRlc3RzL2Zhc3QvZXZlbnRzL21vdXNlLWN1 cnNvci1jaGFuZ2UtZXhwZWN0ZWQudHh0CkBAIC0wLDAgKzEsMjQgQEAKK1Rlc3QgdGhhdCBtb3Vz ZSBjdXJzb3JzIGFyZSBjaGFuZ2VkIGNvcnJlY3RseSBvbiBtb3VzZSBldmVudHMuCisKK09uIHN1 Y2Nlc3MsIHlvdSB3aWxsIHNlZSBhIHNlcmllcyBvZiAiUEFTUyIgbWVzc2FnZXMsIGZvbGxvd2Vk IGJ5ICJURVNUIENPTVBMRVRFIi4KKworCitCdWcgNTMzNDEKKworCitNb3VzZSBtb3ZlCitDdXJz b3IgSW5mbzogdHlwZT1UeXBlSGFuZCBob3RTcG90PTAsMAorCitNb3VzZSBkb3duCitDdXJzb3Ig SW5mbzogdHlwZT1UeXBlUHJvZ3Jlc3MgaG90U3BvdD0wLDAKKworTW91c2UgaG9sZCBkb3duLCBt b3ZlCitDdXJzb3IgSW5mbzogdHlwZT1UeXBlSGFuZCBob3RTcG90PTAsMAorCitNb3VzZSB1cAor Q3Vyc29yIEluZm86IHR5cGU9VHlwZUhlbHAgaG90U3BvdD0wLDAKKworUEFTUyBzdWNjZXNzZnVs bHlQYXJzZWQgaXMgdHJ1ZQorCitURVNUIENPTVBMRVRFCisKZGlmZiAtLWdpdCBhL0xheW91dFRl c3RzL2Zhc3QvZXZlbnRzL21vdXNlLWN1cnNvci1jaGFuZ2UuaHRtbCBiL0xheW91dFRlc3RzL2Zh c3QvZXZlbnRzL21vdXNlLWN1cnNvci1jaGFuZ2UuaHRtbApuZXcgZmlsZSBtb2RlIDEwMDY0NApp bmRleCAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwLi5iOWNlY2VjODVl MGIzYjRhNDY3YzJjNzQxNmI4MzdiZTM2M2E4ZThiCi0tLSAvZGV2L251bGwKKysrIGIvTGF5b3V0 VGVzdHMvZmFzdC9ldmVudHMvbW91c2UtY3Vyc29yLWNoYW5nZS5odG1sCkBAIC0wLDAgKzEsODMg QEAKKzwhRE9DVFlQRSBodG1sPgorPGh0bWw+Cis8aGVhZD4KKzxzY3JpcHQgc3JjPSIuLi9qcy9y ZXNvdXJjZXMvanMtdGVzdC1wcmUuanMiPjwvc2NyaXB0PgorPHN0eWxlIHR5cGU9InRleHQvY3Nz Ij4KKzwvc3R5bGU+Cis8L2hlYWQ+Cis8Ym9keT4KKzxwIGlkPSJkZXNjcmlwdGlvbiI+PC9wPgor PHA+PGEgaHJlZj0iaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTUzMzQx Ij5CdWcgNTMzNDE8L2E+PC9wPgorPGRpdiBpZD0idGVzdC1jb250YWluZXIiPgorICAgIDxkaXYg aWQ9InRhcmdldCIgb25Nb3VzZURvd249InN0eWxlLmN1cnNvcj0ncHJvZ3Jlc3MnO2V2ZW50LnBy ZXZlbnREZWZhdWx0KCk7IiBvbk1vdXNlTW92ZT0ic3R5bGUuY3Vyc29yPSdwb2ludGVyJzsiIG9u TW91c2VVcD0ic3R5bGUuY3Vyc29yPSdoZWxwJzsiIHN0eWxlPSJjdXJzb3I6cG9pbnRlcjsiPlBs YXkgd2l0aCBtb3VzZSBvbiB0aGlzIGVsZW1lbnQuIEN1cnNvcnMgY2hhbmdlIG9uIGV2ZW50cyAt IG1vdXNlbW92ZTogcG9pbnRlcihoYW5kKSwgbW91c2Vkb3duOiBwcm9ncmVzcywgbW91c2V1cDog aGVscC48L2Rpdj4KKzwvZGl2PgorPGJyLz4KKzxkaXYgaWQ9ImNvbnNvbGUiPjwvZGl2PgorPHNj cmlwdD4KK2Rlc2NyaXB0aW9uKCJUZXN0IHRoYXQgbW91c2UgY3Vyc29ycyBhcmUgY2hhbmdlZCBj b3JyZWN0bHkgb24gbW91c2UgZXZlbnRzLiIpOworCitpZiAoIXdpbmRvdy5ldmVudFNlbmRlcikg eworICAgIHRlc3RGYWlsZWQoJ1RoaXMgdGVzdCByZXF1aXJlcyBEdW1wUmVuZGVyVHJlZScpOwor fQorCitpZiAod2luZG93LnRlc3RSdW5uZXIpIHsKKyAgICB0ZXN0UnVubmVyLmR1bXBBc1RleHQo KTsKKyAgICB0ZXN0UnVubmVyLndhaXRVbnRpbERvbmUoKTsKKyAgICB3aW5kb3cuanNUZXN0SXNB c3luYyA9IHRydWU7Cit9CisKK2Z1bmN0aW9uIGRlYnVnQ3Vyc29yKHRhcmdldCwgdHlwZSkgewor ICAgIHRhcmdldC5zdHlsZS5jdXJzb3IgPSB0eXBlOworICAgIGRlYnVnKCdDdXJzb3IgSW5mbzog JyArIHdpbmRvdy5pbnRlcm5hbHMuZ2V0Q3VycmVudEN1cnNvckluZm8oZG9jdW1lbnQpKTsKK30K KworZnVuY3Rpb24gcnVuVGVzdChwcmVwYXJlLCBuZXh0KSB7CisgICAgcHJlcGFyZSgpOworICAg IHNldFRpbWVvdXQoZnVuY3Rpb24oKSB7CisgICAgICAgIGRlYnVnKCdDdXJzb3IgSW5mbzogJyAr IHdpbmRvdy5pbnRlcm5hbHMuZ2V0Q3VycmVudEN1cnNvckluZm8oZG9jdW1lbnQpKTsKKyAgICAg ICAgZGVidWcoJycpOworICAgICAgICBuZXh0KCk7CisgICAgfSwgMSk7Cit9CisKK2Z1bmN0aW9u IHRlc3RzRG9uZSgpIHsKKyAgICAvLyBUaGlzIHRleHQgaXMgcmVkdW5kYW50IHdpdGggdGhlIHRl c3Qgb3V0cHV0IC0gaGlkZSBpdAorICAgIGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCd0ZXN0LWNv bnRhaW5lcicpLnN0eWxlLmRpc3BsYXkgPSAnbm9uZSc7CisgICAgZmluaXNoSlNUZXN0KCk7Cit9 CisKKy8vIENhbid0IGRvIGFueXRoaW5nIHVzZWZ1bCBoZXJlIHdpdGhvdXQgZXZlbnRTZW5kZXIK K2lmICh3aW5kb3cuZXZlbnRTZW5kZXIpIHsKKyAgICB2YXIgdGFyZ2V0ID0gZG9jdW1lbnQuZ2V0 RWxlbWVudEJ5SWQoJ3RhcmdldCcpOworICAgIAorICAgIHZhciB0ZXN0cyA9IFsKKyAgICAgICAg ZnVuY3Rpb24oKSB7CisgICAgICAgICAgICBkZWJ1ZygnTW91c2UgbW92ZScpOworICAgICAgICAg ICAgZXZlbnRTZW5kZXIubW91c2VNb3ZlVG8odGFyZ2V0Lm9mZnNldExlZnQgKyAzLCB0YXJnZXQu b2Zmc2V0VG9wICsgMyk7CisgICAgICAgIH0sIGZ1bmN0aW9uKCkgeworICAgICAgICAgICAgZGVi dWcoJ01vdXNlIGRvd24nKTsKKyAgICAgICAgICAgIGV2ZW50U2VuZGVyLm1vdXNlRG93bigpOwor ICAgICAgICB9LCBmdW5jdGlvbigpIHsKKyAgICAgICAgICAgIGRlYnVnKCdNb3VzZSBob2xkIGRv d24sIG1vdmUnKTsKKyAgICAgICAgICAgIGV2ZW50U2VuZGVyLm1vdXNlTW92ZVRvKHRhcmdldC5v ZmZzZXRMZWZ0ICsgNCwgdGFyZ2V0Lm9mZnNldFRvcCArIDMpOworICAgICAgICB9LCBmdW5jdGlv bigpIHsKKyAgICAgICAgICAgIGRlYnVnKCdNb3VzZSB1cCcpOworICAgICAgICAgICAgZXZlbnRT ZW5kZXIubW91c2VVcCgpOworICAgICAgICB9CisgICAgXTsKKyAgICAKKyAgICB2YXIgaSA9IDA7 CisgICAgZnVuY3Rpb24gbmV4dFRlc3QoKSB7CisgICAgICAgIGlmIChpIDwgdGVzdHMubGVuZ3Ro KSB7CisgICAgICAgICAgICBydW5UZXN0KHRlc3RzW2krK10sIG5leHRUZXN0KTsKKyAgICAgICAg fSBlbHNlIHsKKyAgICAgICAgICAgIHRlc3RzRG9uZSgpOworICAgICAgICB9CisgICAgfQorICAg IG5leHRUZXN0KCk7Cit9CisKKzwvc2NyaXB0PgorPHNjcmlwdCBzcmM9Ii4uLy4uL2Zhc3QvanMv cmVzb3VyY2VzL2pzLXRlc3QtcG9zdC5qcyI+PC9zY3JpcHQ+Cis8L2JvZHk+Cis8L2h0bWw+Cg==