Mouse cursor not changing if a pointer is not moved in Webkit-based browsers

Question

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.

Answer 1

This is a well known bug in then webkit engine, and there is no real workaround for it.

Answer 2

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 )

function _repaintCursor() {
    var saveCursor = document.body.style.cursor,
        newCursor = saveCursor ? "" : "wait";
    _setCursor(newCursor);
    _setCursor(saveCursor);
}

function _setCursor(cursor) {
    var wkch = document.createElement("div");
    var wkch2 = document.createElement("div");
    wkch.style.overflow = "hidden";
    wkch.style.position = "absolute";
    wkch.style.left = "0px";
    wkch.style.top = "0px";
    wkch.style.width = "100%";
    wkch.style.height = "100%";
    wkch2.style.width = "200%";
    wkch2.style.height = "200%";
    wkch.appendChild(wkch2);
    document.body.appendChild(wkch);
    document.body.style.cursor = cursor;
    wkch.scrollLeft = 1;
    wkch.scrollLeft = 0;
    document.body.removeChild(wkch);
}

Answer 3

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 call elem.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:

var $document = $(document);
$document.ready(function() {
    var $test = $("#test");
    $document.keydown(function(e) {
        e.shiftKey && $test.css("cursor", "pointer");
        $test[0].scrollTop;
    });
});

Answer 4

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:

chromium-browser --kiosk 'http://server:4662/1920x1080/status.html?id=42'

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:

function $(id) {return document.getElementById(id);}

function onLoad()
{
    window.setTimeout(hideCursor, 1000);

    function hideCursor() {
        $('content').style.cursor = 'url(/blankCursor.gif),auto';
    }
}

window.onload = onLoad;

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 put url(/blankCursor.gif), it won't honor the declaration.