1267724 - [GTK3] FF 46 uses the wrong cursor theme

Status: RESOLVED INACTIVE

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

Description

[donrhummy]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160421124000

Steps to reproduce:

Just updated to Firefox 46 on openSUE Linux.


Actual results:

Within the browser only, the cursor is showing in the Adwaita theme despite my cursor theme being "Oxygen whtie". (It uses this incorrect theme even when hovering over tabs)


Expected results:

It should have continued using my OS/Desktop-level cursor theme as FF 45 did.

Comment 1

[donrhummy]

More Info: If I go into the Desktop Config (KDE) and re-choose my cursor theme as Oxygen White, then it now shows correctly in Firefox.

It seems like there must be an issue with FF 46 not picking up the cursor theme on update (or possibly install) and using either the wrong one or a fallback, but it gets set properly (at least for now, haven't restarted) on a cursor theme reset.

Comment 2

[Mats Palmgren (inactive)]

That's odd.  I'm pretty sure Firefox doesn't cache anything related to GTK themes.
I'm guessing you're using the Firefox that OpenSUSE distributes and not the builds
from mozilla.com, so it might be better to report this issue to OpenSUSE.

Comment 3

[:Gijs (he/him)]

46 is built with gtk3 by default. Maybe your gtk3 theme settings are different from the gtk2 settings?

Comment 4

[donrhummy]

More Info: restart resets the cursor again.

Comment 5

[donrhummy]

(In reply to :Gijs Kruitbosch from comment #3)
> 46 is built with gtk3 by default. Maybe your gtk3 theme settings are
> different from the gtk2 settings?

But then why would resetting the cursor theme change how the cursor appears in Firefox?

Comment 6

[donrhummy]

(In reply to Mats Palmgren (:mats) from comment #2)
> That's odd.  I'm pretty sure Firefox doesn't cache anything related to GTK
> themes.
> I'm guessing you're using the Firefox that OpenSUSE distributes and not the
> builds
> from mozilla.com, so it might be better to report this issue to OpenSUSE.

Nope. I always uninstall the openSUSE build. They take too long to release updates so I always install from mozilla.org.

Comment 7

[Karl Tomlinson (:karlt)]

Reproduces here thanks.

It is a bug in GTK.  Reproduces with gtk3-widget-factory, when hovering over the editable text entries or view.

Comment 8

[Karl Tomlinson (:karlt)]

GTK+ 3.4 gives the expected behavior, so a regression somewhere between there and 3.16.7.

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 10

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 11

[Andrew Sutherland [:asuth] (he/him)]

Attachment: Demonstration patch to introduce a "widget.gtk-cursor-theme-override" pref v1

I looked into this because I'm trying something out with a touchscreen using a second cursor[1]. This resulted in crazy flickering of the cursor. So I tried out a transparent cursor theme[2] but setting the XCURSOR_THEME variable didn't work.

Digging into the GTK source and revision control history it seems like:

• GTK uses libXcursor under the hood, and libXcursor does the default thing it does which presumably includes processing XCURSOR_THEME.
• gtk_settings_create_for_display calls settings_update_cursor_theme which gets "gtk-cursor-theme-name" and if it gets a value back calls gdb_display_set_cursor_theme which clobbers whatever XCURSOR_THEME initialized things to.
• It's always done something roughly like this. The difference is presumably that it started reliably getting a value when it looks up "gtk-cursor-theme-name". I think the lookup process looks like this:
  • Under X11:
    • gdksettings.c maps "gtk-cursor-theme-name" to xsettings name "Gtk/CursorThemeName"
    • gnome-settings-daemon maps "org.gnome.desktop.interface" "cursor-theme" to "Gtk/CursorThemeName"
  • Under Wayland
    • gdkdisplay-wayland.c has a direct mapping for "org.gnome.desktop.interface" "cursor-theme" to "gtk-cursor-theme-name

So I created the patch that I'm attaching here that creates a widget.gtk-cursor-theme-override preference that's applied in the parent (chrome) process when initializing. This seems to work. This could also be made to pull XCURSOR_THEME from the environment as part of a fallback path or something. That said, this seems like a pretty extreme customization to land in the tree as a workaround for X and gtk multi-pointer touch-screen issues. If Firefox were going to do something to aid the touch-screen case, it might be better for touch events to turn off the cursor, leaving it for mouse movement to turn it back on.

1: Created via:

• xinput create-master touchy
• xinput reattach "Weida Hi-Tech CoolTouchR System " "touchy pointer" (the device name being specific to my touchscreen)

2: I used https://github.com/shmibs/xcursor-transparent-cursor to create a transparent cursor theme

Comment 12

[Andrew Sutherland [:asuth] (he/him)]

Er, as I re-read the bug I think I was mentally creating a mash-up of bug 336665 and my own google searches in my mind relating to XCURSOR_THEME as a means of overriding gtk, with only small pieces of this bug included. Apologies for the largely off-topic response. I'm going to leave my comment visible since the setting mapping links are potentially relevant to explaining the specific situation on this bug.

Comment 13

[Sylvestre Ledru [:Sylvestre]]

No activity for years, closing.
Please reopen if this is still impacting you.