1454937 - System screen scaling + css cursor hotspot = wrong cursor shift

Status: RESOLVED DUPLICATE of bug 1560081

(Core :: Widget: Win32, defect, P3)

Description

[juwagn]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180323154952



Actual results:

On many devices with high resolution displays Windows10 reuses scaling of 125% etc.
FireFox in its last version 59 (another unchecked) does not respect system scaling value for hotspot shift. As result the cursor is scaled by zoom but hotspot is incorrectly placed. I highly assume transform-origin(if something like exists by css cursors) is not respected.


Expected results:

It should behave as example on Chrome browsers where hotspot tranform origin is respected and so cursor correctly placed.

Comment 1

[r4ndomstuff]

I have wrong cursor shift for my custom SVG cursor in X11 on Linux.
It only occurs sometimes when I move the cursor onto the element I applied my 32x32 SVG cursor too.
Initially it will be at the wrong position but if I move the mouse around on the element, the cursor "snaps" to where it should have been all along.
CSS: {cursor: url("cursor.svg") 15 15, auto;}

However I don't have any dpi scaling.

Comment 2

[r4ndomstuff]

Most people probably don't notice it because most cursors pretty much use the top left of the image as hotspot but honestly this is a pretty heavy deficiency.

Comment 3

[Ray Kraesig [:rkraesig]]

This was later fixed under bug 1560081. Closing as RESOLVED DUPLICATE.

@r4ndomstuff, that sounds like a valid but completely unrelated bug; please create a new issue (including a test case) and file it under Widget: Gtk.

Comment 4

[juwagn]

(In reply to r4ndomstuff from comment #2)

Most people probably don't notice it because most cursors pretty much use the top left of the image as hotspot but honestly this is a pretty heavy deficiency.
Hello,

that sounds very similar to another bug i have reported many years ago which was e10s related. (e10s is also multi-processor mode)
https://bugzilla.mozilla.org/show_bug.cgi?id=1336764
in short, the cursor won't change as long you don't move the the mouse at least for 1px.
The example can be checked and the issue persist even 8 years later.
On Chrome (and Chromium based browsers) the example works as expected.
Probably your bug is related to this one too, however not so sure about.
So far i know e10s was forcibly enabled since v68, and nowadays buggy e10s can't be disabled that easy anymore.
And so the issue with e10s is almst forever lasting now in FireFox browser.

Comment 5

[Ray Kraesig [:rkraesig]]

(In reply to juwagn from comment #4)

Hello,

that sounds very similar to another bug i have reported many years ago which was e10s related. (e10s is also multi-processor mode)
https://bugzilla.mozilla.org/show_bug.cgi?id=1336764
in short, the cursor won't change as long you don't move the the mouse at least for 1px.
The example can be checked and the issue persist even 8 years later.

Yes, it would be good to get some more eyes on that bug. I can confirm the test case still works (EDIT: well, fails) on Windows.

@r4ndomstuff, when you file your bug, can you check if the test case in bug 1336764 works on Linux?

• If so, please add bug 1336764 to the "see also" list for your new bug.
• If not, please needinfo? me in bug 1336764, and I'll move it to Widget: Win32.