| Summary: | Changing cursor style has no effect until the mouse moves | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Gérard Talbot <browserbugs2> | ||||
| Component: | CSS | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | ap, bugs, darin, deanm, estade, evan, jiyuluna, matt11ag-webkitbugs, mjs, rniwa, scherkus, schmidt.christian, simon.fraser | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | 523.x (Safari 3) | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| URL: | http://www.gtalbot.org/DHTMLSection/Positioning.html | ||||||
| Bug Depends on: | 53280 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
Confirmed on Mac OS, so moving to All/All. The Mac version has an even worse behavior, since it cannot display most .cur cursors, but the described problem appears to occur, too. *** Bug 19925 has been marked as a duplicate of this bug. *** *** Bug 22296 has been marked as a duplicate of this bug. *** *** Bug 23079 has been marked as a duplicate of this bug. *** Duplicates have examples and, I think, some slightly better explanations. this also occurs for non-custom cursors. For example, see http://code.google.com/p/chromium/issues/detail?id=34075 (changing zoom level doesn't change the zoom icon until after a mouse move event) If we address the basic problem here, we probably still won’t resolve the case where the mouse is down, which would be needed to make the closed-hand example work. Generally speaking we make no cursor adjustments while the mouse is down. We don’t want to change the cursor based on what the mouse is over as you drag with the mouse down. It would be interesting to see how the other browsers behave. Do they adjust the cursor based on style changes in the element you were over when the mouse went down? In Firefox 3.6 on Linux, dragging the map gives me the hand cursor. As soon as I drag from there over another HTML element (including the floating map controls) the cursor changes to the cursor used by that control. Dragging outside of the map also resets the cursor. And in all cases, dragging back into the map after the cursor changing puts the cursor back into the dragging-hand cursor. So from that I guess that maps changes the cursor of the map widget to the custom cursor on mouse down, and Firefox obeys the cursor of whatever the mouse is currently over, regardless of the mouse down state. More common uses of dragging, like dragging a link, use browser-level support for drag icons etc so the mouse cursor is unaffected by the page. http://panic.com/goods is another site that uses dnd heavily. There, they have no custom mouse cursor but I do notice that when I drag an item over a link I have the normal arrow cursor throughout, not the hand cursor, because the simulated drag icon is beneath the cursor. If I mouse-wheel *while* dragging, their simulated drag icon gets out of position and I can see my mouse cursor change to the hand when I hover a link. (Weirdly, maps loses my mouse drag if I drag out the left or right side of the window, but not the bottom or top! There could be other bugs here in both maps and Firefox's Linux support, so it is probably worth testing in a more popular browser. panic.com didn't have this problem.) > Generally speaking we make no cursor adjustments while the mouse is down. We don’t want to change the cursor based on what the mouse is over as you drag with the mouse down. In my DHTML demo page, the cursor once Activated is over, remains over that <div id="idTitlePosition">... pseudo-title-bar as it dynamically moves to match cursor position. > It would be interesting to see how the other browsers behave. If I understand correctly your question here, then, yes, other browsers change the cursor based on what the mouse is over as you drag with the mouse down. { Steps: in this very page, mousedown the left button and then move the cursor Actual (with Firefox 3.6.13): all the text become selected/highlighted and the cursor has the I-beam shape. But when the cursor is over a link, then the cursor changes to pointer (a pointing hand). Actual (with Chrome 8.0.552.237): all the text become selected/highlighted and the cursor has the I-beam shape. When the cursor is over a link, then the cursor remains a text (I-beam shape) cursor. } { Steps: I load http://www.gtalbot.org/DHTMLSection/Cursors.html#CSS2 and then mousedown the left button and then move the cursor in the "Notes" column (from auto row at the top to <URI> row at the bottom). Actual (with Firefox 3.6.13): all the text in the first 3 columns become selected, highlighted while the cursor changes accordingly to become the cursor name given in the first column Actual (with Chrome 8.0.552.237): all the text in the first 3 columns become selected, highlighted while the cursor becomes and remains a text (I-beam shape) cursor. } > Do they adjust the cursor based on style changes in the element you were over when the mouse went down? Yes with Firefox 3.6.13. No with Chrome 8.0.552.237. I can check with IE8 later if you want. ------------ FWIW, 2 Drag-n-drop HTML5 demos (using dragstart, dragover, dragenter, dragleave events): http://html5demos.com/drag http://html5demos.com/drag-anything regards, Gérard > Do they adjust the cursor based on style changes in the element you were over when the mouse went down?
While following the steps given before for the 2 urls...
Yes with Firefox 3.6.13 (under Linux) and Opera 11.0 (build 1156; under Windows XP).
No with IE8 (under Windows XP) and Chrome 8.0.552.237 (under Linux).
Gérard
> Do they adjust the cursor based on style changes in the element you were over when the mouse went down?
While following the steps given in #c10 for the 2 urls...
Yes with Konqueror 4.5.5 (Qt 4.7.0, i686, Linux 2.6.35-24-generic-pae;).
Gérard
There are multiple things wrong:
1) Changing CSS cursor style won’t trigger a cursor change until the mouse moves.
2) If an element’s position change affects the cursor because it moves under the cursor our moves out from under the cursor the cursor won’t change until the mouse moves.
3) Hover effects also don’t change in cases like (2).
4) Changing CSS cursor style doesn’t have any effect while the mouse is down.
I am going to post a patch that fixes only (1). We should use separate patches for the other issues.
(In reply to comment #13) > We should use separate patches for the other issues. I mean separate bug reports. Created attachment 80368 [details]
Patch
Comment on attachment 80368 [details]
Patch
I don't think this handle the case where an element's cursor style doesn't change, but layout moves the element under the cursor.
(In reply to comment #16) > I don't think this handle the case where an element's cursor style doesn't change, but layout moves the element under the cursor. Yes, correct. As I said above, my patch fixes only issue (1) above and you are citing my issue (2) above. I discussed this with Mitz and Hyatt, and Mitz pointed out (3) above and Hyatt thought we should fix cursors and hover at the same time. interested in the fix for (1) since I hacked up a hide-the-cursor-over-video-playback demo! cool!! Committed r76891: <http://trac.webkit.org/changeset/76891> Reopening because the patch caused all the layout tests to crash on SnowLeopard. Re-landed with missing null check: <http://trac.webkit.org/changeset/76999>. We can either close this bug or re-purpose it to cover (4) since the test case in this bug requires (4). Even clearer would be to close this and file new separate bugs for (2), (3), and (4). Did you forget to make areNonIdenticalCursorListsEqual inline or was it intentional? It's only called by areCursorsEqual, which is declared static inline. http://trac.webkit.org/changeset/76999/trunk/Source/WebCore/rendering/RenderObject.cpp (In reply to comment #23) > Did you forget to make areNonIdenticalCursorListsEqual inline or was it intentional? It was intentional and in fact it’s the reason there are two functions. Since almost no objects have cursor lists, I wanted to put the much less hot code behind a function call. Probably not obvious so I should have put in a comment. |
Steps to reproduce: 1. Load provided URL 2. Mousedown over the "Position" pseudo-titlebar of the form and hold the mousedown without moving the mouse Actual results: You see a custom hand-grab cursor which displays an open hand with 5 fingers Expected results: The custom hand-grab cursor displaying an open hand with 5 fingers should become, should change into a custom hand-grabbing cursor which display a closed hand Relevant code involved: <body onload="init();"> (...) <div id="idTitlePosition" title="You can drag and move this position control box form">Position<img (...)></div> function init() { if (document.addEventListener) { document.getElementById("idTitlePosition").addEventListener("mousedown", Activate, false); (...) In Position.css (around line 43): #idTitlePosition { (...) cursor: url("../GRAPHICS/ICO/grab.cur"), move; } In Position.js (around line 230): function Activate (evt) { TextBoxToBeMoved = (evt) ? evt.currentTarget : window.event ? event.srcElement : null; TextBoxToBeMoved.style.cursor = "url('../GRAPHICS/ICO/grabbing.cur'), -moz-grabbing"; Notes: - the provided URL is not a reduced testcase. - MSIE 6, MSIE 7, Firefox 2.0.0.4 get the expected results. - Mozilla used to have a similar bug: Mozilla-Bug 293510 dynamic changes of 'cursor' property don't work until mouse moves https://bugzilla.mozilla.org/show_bug.cgi?id=293510