Let's assume that we have simple jQuery code like the following:
var $document = $(document);
$document.ready(function() {
var $test = $("#test");
$document.keydown(function(e) {
e.shiftKey && $test.css("cursor", "pointer");
});
});
The problem is that WebKit does not change the #test
block mouse cursor if the mouse pointer is moved over the #test
block, and the Shift key is pressed then. But as soon as you move the cursor, Chrome and Safari change the cursor style to pointer
- exactly as it's expected but without mouse move. This bug (?) is not relevant to Firefox, and I didn't check it under Internet Explorer and Opera...
So, did anyone have experience with the same trouble? Perhaps, is there a workaround for that?
Thanks in advance.
I had this problem using Chromium 11.0.696.65. I was able to solve it with a little delayed JavaScript.
I was trying to make an electronic sign consisting of a large LCD monitor driven by a small diskless industrial computer running Chromium on Ubuntu. On start up, it runs something like:
The downloaded page has an XHR polling loop which receives a JavaScript object literal whenever anything changes relating to
id=42
, at which time, it updates the display appropriately. There is CSS specifying all elements should have a blank mouse pointer.Problem was, Chrome's request-in-progress mouse pointer was left sitting on the screen. It disappeared as soon as a I moved the mouse. However, the real sign won't have a mouse attached, much less a user to move it.
I added the following script:
Now, the annoying cursor shows up briefly on startup, but vanishes in a second. Then the sign runs cursorless until the next startup (days or weeks).
BTW, the
,auto
appears to be another Chromium bug. I found if I just puturl(/blankCursor.gif)
, it won't honor the declaration.This is a well known bug in then webkit engine, and there is no real workaround for it.
I've found a workaround to the problem.
It seems the cursor is changed if you force the browser to reflow. So, if you set the cursor on
elem
and then callelem.scrollTop
(or any number of properties which trigger a reflow), the cursor will update in place.So in your case the code would end up being:
Contrary to what was said before, this workaround I found from David Becker seems to be effective. (The fixes for the browsers are in the pipe. See https://bugs.webkit.org/show_bug.cgi?id=101857 )