Input.set_mouse_cursor doesn't immediately refresh the cursor in HTML5 exported games

[Jeto143]

Godot version:

3.1.1

OS/device including version:

Windows 10 (up-to-date) - Chrome (latest version) / Firefox (latest version)

Issue description:

When running a game on a browser, calling Input.set_mouse_cursor with a custom cursor will (often, see below) not update the cursor until the mouse is moved again. Sometimes (apparently only on Chrome), the cursor will also become hidden when you attempt to change it again into the same one (easily fixable by storing the last set cursor to not call it twice in a row, but still not ideal).

Notes:

This kinda happens randomly depending on browsers, settings, and maybe setup / graphic card / etc. On my own project, it only happens on Firefox, but sometimes stops occurring when debug is enabled. At work, it also happens on Chrome (same build of the game).

Demo:

https://pleesher.com/resources/temp/browser_cursor_bug/browser_cursor_bug.html

Wait until the screen is grey (scene fully loaded). Click anywhere to set the cursor, but try not moving the mouse right after doing so. The default cursor stays until you move it again. (As mentioned above, on Chrome, clicking again also makes the cursor disappear until the following move, and so on.)

Steps to reproduce:

extends Node2D

onready var alt_cursor = preload('res://left_ptr.png')

func _input(event):
    if event is InputEventMouseButton and event.button_index == BUTTON_LEFT and event.pressed:
        Input.set_custom_mouse_cursor(alt_cursor)

This is the exact code used in the demo above. left_ptr.png is a 32x32 cursor.

[KoBeWi]

I tested on Chrome, Edge and Firefox in 3.2.3 rc3 and it happens only in Firefox. This is possibly browser issue, not engine.

[Faless]

Yes, this seems to be a Firefox specific issue (it does not repaint the cursor after css style change until the cursor is moved again). I'm closing this, since to my knowledge we can't fix this, feel free to comment/reopen if you think otherwise.

[Calinou]

@Faless We should still document this limitation in the class reference.

[Faless]

We should still document this limitation in the class reference.

@Calinou I'm not sure how we would go at that, it feels weird to document a bug of a specific external software in one of the engine function, but here's the relevant issue on bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1336764