Closed Bug 1876366 Opened 2 years ago Closed 2 years ago

Many X11 cursor shapes stopped working in 123.

Categories

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

Firefox 122
defect

Tracking

()

RESOLVED FIXED
125 Branch
Tracking Status
firefox-esr115 --- unaffected
firefox123 --- wontfix
firefox124 --- wontfix
firefox125 --- fixed

People

(Reporter: tor, Assigned: stransky)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

Steps to reproduce:

X11 with original bitmap cursors (i.e. without the themed cursors) have stopped working in Firefox 123 beta. They worked in Firefox 122.

Disable the X11 cursor theme to get the original bitmap cursors.

Then hover over any hyperlinks, or use the https://developer.mozilla.org/en-US/docs/Web/CSS/cursor demo.

Actual results:

The cursor does not change shape for "pointer".
The cursor does not change shape for "help".
The cursor changes to the wrong shape for "grab".

Expected results:

"pointer" should be the hand with the finger pointing left.
"help" should be the question mark with an arrow pointing down.
"grab" should be a hand with fingers spread out.

In 123 "grab" is using the old icon for "pointer".

The Bugbug bot thinks this bug should belong to the 'Firefox::Theme' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Theme

Would you be willing to use mozregression to find a more accurate regression range?

Flags: needinfo?(tor)

I have narrowed it down to the bug fixes for 1871863 and 1872961.

With changeset https://hg.mozilla.org/integration/autoland/rev/c71d09ab8b2b32c1cc00a0eba6f8f3b72a61e5fa most of the cursors broke when not using a Gtk cursor theme (the "help" cursor becomes the default arrow cursor, etc).

With changeset https://hg.mozilla.org/integration/autoland/rev/fe17a0f69c5993a97f6d9e167b166747625771a6 the "pointer" cursor (pointing hand) also becomes an arrow.

Here is a list of the original bitmap cursorfont cursors that are always available when a cursor theme is not installed:

https://tronche.com/gui/x/xlib/appendix/b/

Flags: needinfo?(tor)
Keywords: regression
Regressed by: 1871863, 1872961

(In reply to tor from comment #3)

I have narrowed it down to the bug fixes for 1871863 and 1872961.

Both bugs were in Core::Widget::GTK so I''m moving this bug over there for triage.

Component: Theme → Widget: Gtk
Product: Firefox → Core

Hi,

X11 with original bitmap cursors (i.e. without the themed cursors) have stopped working in Firefox 123 beta. They worked in Firefox 122.

Could you point me to a bitmap cursor to install and exactly how you configured your system?

I don't think anything changed in GTK 3 wrt bitmap cursors and the bug would likely be there.

Flags: needinfo?(tor)

The easiest way to test this is to disable the Gtk+ Adwaita cursor theme by (temporarily) setting the permissions to the cursor theme directory to make it unreadable and restart the X server:

sudo chmod 0 /usr/share/icons/Adwaita/cursors

Now you have nice and crisp bitmap cursors, and should be able to replicate the bug.

Looking at the patch that introduced this regression, it changed from GDK_HAND2 to "grab" when it probably should have changed it to "hand2" and/or used a fallback if gdk_cursor_new_from_name can't find the old "hand2" name.

Flags: needinfo?(tor)

Alright so a way to replicate this is:

sudo chmod 0 /usr/share/icons/Adwaita/cursors
GDK_BACKEND=x11 gtk3-demo

go to the cursors demo

This is a GTK 3 bug by the looks of it and will have to be investigate there.

Priority: -- → P3
See Also: → 1881136
Flags: needinfo?(stransky)

Xfce user here, same problem.

This is a GTK 3 bug by the looks of it and will have to be investigate there.

Is there already a bug report filed for it @ GTK?

Might be a good idea to roll back the FF changeset that caused this until this is fixed.

Forgot to mention that my system mouse theme is DMZ...
https://community.linuxmint.com/software/view/dmz-cursor-theme
...which changes to Bibata-Modern-Classic inside Firefox 123.

The GTK issue you linked (6387) isn't clear, has enough information or is the same bug from the looks of it. Please file a new issue.

Might be a good idea to roll back the FF changeset that caused this until this is fixed.

The problem here is that people are moving away from the XCursor themes and dropping support for them nowdays. 1

If this change is reverted then people running GNOME 46 will also have broken cursrors by default and that's a much larger userbase than the 3 people that still use a Bitmap cursor icon theme.

I have this same problem, using KDE/Plasma on X11. I have my cursor theme set to "Oxygen White", but in Firefox the default cursor now changes to "Adwaita". However, when I hover over a link, it changes to the pointer using the correct "Oxygen White" theme instead, as it does if I hover over text with the selector cursor. So it doesn't seem to be a problem of not being able to support the theme. It's just the default cursor that doesn't respect the theme.

After looking at why some non-default icons where working but not the default one, I found out it's just a matter of the cursor theme I was using didn't have any cursor icon named "default"! The one that seemed to be being used as default was named "left_ptr", so I copied that to the same directory with the name "default" and that solved the problem.

In my system, that was as follows (as root):

cp /usr/share/icons/Oxygen_White/cursors/left_ptr /usr/share/icons/Oxygen_White/cursors/default

After loging out and in again it all worked as before.

After looking at why some non-default icons where working but not the default one, I found out it's just a matter of the cursor theme I was using didn't have any cursor icon named "default"! The one that seemed to be being used as default was named "left_ptr", so I copied that to the same directory with the name "default" and that solved the problem.

Thank you for the debugging and detailed report. This I believe is a separate issue than the bitmap fonts mentioned above and it was fixed a couple ago with the following Merge Requests:

https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6649

https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6835

Not sure if Firefox is bundling GTK anymore but also maybe we could increase the gtk3 version during configure so people know to update their distro packages when trying to build on ancient/lts distros.

The story so far:

X11 was released in 1984 with support for shaped cursors. The cursor shapes
come from a standard X11 "cursorfont" font, accessible in Xlib from XCreateGlyphCursor.

Lots of software was written using the standard cursor names this provided.
X11 today has support for using a cursor theme that defines custom images for each
cursor, using the same names as the old cursorfont.

At some point after this, the Gnome project adds some new cursor names based
on the CSS specification to their cursor theme. This cursor theme is installed
globally on the X server and affects every application, whether Gtk or Gnome or not.

Recently, Gnome decided that it doesn't like the old cursor names and removed
all of the old standard cursors from their cursor theme! This broke A LOT of software,
including Firefox.

https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/commit/74e9b79471236320d2af4925d6c5bb7df22380ce

It looks like they've realized the magnitude of their error, and provided symlinks for
the more commonly used standard X11 cursors in a patch:

https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/commit/0d44a3fec0171cb8689e79df0186082907533383

However, Firefox has now decided to use the new Gnome-specific cursor names instead of the standard cursors:

https://hg.mozilla.org/integration/autoland/rev/c71d09ab8b2b32c1cc00a0eba6f8f3b72a61e5fa
https://hg.mozilla.org/integration/autoland/rev/fe17a0f69c5993a97f6d9e167b166747625771a6

Unfortunately these cursors are ONLY available in Gnome environments. If you're using a custom cursor theme
like the DMZ themes, or simply haven't installed Gnome, these cursors are not available.

Is it possible for Firefox support both the new and the old, by first looking for the new Gnome/Gtk
name (pointer) and if that isn't found, try the standard X11 cursor name (hand2)?

Does gdk_cursor_new_from_name(display, "pointer") return NULL if the current cursor theme doesn't have a
"pointer"-named cursor, or there is no cursor theme and X11 is falling back to the original cursorfont?

Recently, Gnome decided that it doesn't like the old cursor names and removed
all of the old standard cursors from their cursor theme! This broke A LOT of software,
including Firefox.

Unfortunately these cursors are ONLY available in Gnome environments. If you're using a custom cursor theme
like the DMZ themes, or simply haven't installed Gnome, these cursors are not available.

Yes this broke software which still used 10+ year old deprecated APIs. However the old xcursors still work with the new API, modulo bugs see gtk commits above.

Is it possible for Firefox support both the new and the old, by first looking for the new Gnome/Gtk
name (pointer) and if that isn't found, try the standard X11 cursor name (hand2)?

The code already does this as-is. The new API or commit didn't break using existing xcuror themes. There's code in GTK that even falls back to xcursor names if the CSS name is not provided.

https://gitlab.gnome.org/GNOME/gtk/-/blob/84407521965b23d4bcebd95ca77741694cdd6983/gdk/wayland/gdkcursor-wayland.c#L86-139

What broke in this case is:

  • Handling of bitmap font, which seems to be an issue in GTK itself and I haven't had a chance to debug this yet.

  • People using outdate versions of GTK 3 that don't have a couple of fallback fixes.

Firefox needs to be linking against at least GTK 3.24.39 or what soon will become 3.24.42. I will ping people and see if we can get another GTK 3 release out.

Does gdk_cursor_new_from_name(display, "pointer") return NULL if the current cursor theme doesn't have a
"pointer"-named cursor, or there is no cursor theme and X11 is falling back to the original cursorfont?

It only returns NULL if it can't find the cursor requested or a "default" cursor.

I think this may be a problem for ESR releases which run on old systems without regular updates.
We can check recent Gtk3 version as well as active Gnome environment.

Jordan, do you think it's possible to fallback to old cursors in such case?
I don't think we can expect all system will be updated to recent Gtk.

Thanks.

Flags: needinfo?(jordan)
Flags: needinfo?(stransky)
Priority: P3 → P2
Flags: needinfo?(stransky)
Duplicate of this bug: 1881143

Yes, I will take a loot a that, should be easily to add the runtime check based on the gtk version, however the code is gonna look horrible with all the branching but maybe we will find a better way during review.

I will try to find some time to look into it in this or some upcoming evening.

Flags: needinfo?(jordan)

(In reply to Jordan Petridis from comment #19)

Yes, I will take a loot a that, should be easily to add the runtime check based on the gtk version, however the code is gonna look horrible with all the branching but maybe we will find a better way during review.

It may be implemented as separated methods for new/old cursor settings.

So I wrote the version check patch attached below however not yet pushed cause:

While I was writing the commit message I remembered that the gtk fallback fixes only actually affect the case where you only have a css-like cursor theme. The fallback for xcursors has always worked and in fact up till gtk 3.24.42 it was still lookups using some of the old gdk_cursor_new_for_display in a couple of places still. That's what both the Merge Requests above were fixing.

I 've tried to reproduce the issue afterwards in a couple of VMs to no luck.

On ubuntu 22.04 I tried both the binary build from firefox.com and the distro build both worked fine.

I also tested on Linux Mint, both binary builds, distro build and Flatpak all were also fine.

Then I changed the cursor to DMZ which comes preinstalled, but not default in Mint, and Rebooted. Still worked fine

The I repeated the above in Linux Mint Debian edition which was also mentioned in another bug and I still couldn't reproduce the issue.

WIP patch, not submitted for review cause we actually might not need it in the end

For anyone affected by the issue I need the following information from you:

Are there any logs when you launch firefox from the command line?
What distro are you using?
What type of firefox?

  • can you also reproduce with the binary build from firefox.com
  • is it from the distro
  • is it from Flathub or snap
    What Desktop Environment and what version?
    Is it Wayland or Xorg?
    What's the version of GTK you are using (or ideally firefox links against)?
    What cursror are you using?
    And if you can reproduce could you zip up /usr/share/icons and attach it to this bug report.

Thank you.

I've also tested both the firefox.com binaries and the Flahub build on a CentOS 7 VM and the fallback code worked fine and the cursors where there. I don't think this will be an issue for ESR in general.

(In reply to Jordan Petridis from comment #23)

For anyone affected by the issue I need the following information from you:

Are there any logs when you launch firefox from the command line?

No messages at all.

What distro are you using?

Debian.

What type of firefox?

  • can you also reproduce with the binary build from firefox.com

123.0 from firefox.com installed in /opt/firefox

What Desktop Environment and what version?
Is it Wayland or Xorg?

Xorg with NO desktop environment.

What's the version of GTK you are using (or ideally firefox links against)?

Tried both these:

libgtk-3-0_3.24.5-1_amd64.deb

libgtk-3-0_3.24.24-4%2bdeb11u3_amd64.deb

What cursror are you using?

No cursor theme.

Using default X server cursors only (the ones from the cursorfont in /usr/share/fonts/X11/misc/cursor.pcf.gz).

And if you can reproduce could you zip up /usr/share/icons and attach it to this bug report.

/usr/share/icons/Adwaita/cursors directory is NOT present.

Are there any logs when you launch firefox from the command line?
No, nothing at all

What distro are you using?
Debian 12.5 bookworm

What type of firefox
The binary from firefox.com, installed into /opt

What Desktop Environment and what version?
Cinnamon 5.6.8-1

Is it Wayland or Xorg?
Xorg

What's the version of GTK you are using (or ideally firefox links against)?
libgtk-3-0 3.24.38-2~deb12u1

What cursor are you using?
DMZ-White from Debian's dmz-cursor-theme 0.4.5 package

And if you can reproduce could you zip up /usr/share/icons and attach it to this bug report.
This would be ~500 MB...

Additional info: This issue is NOT observed on FreeBSD 14.0-RELEASE-p5 with cinnamon-5.4.9_6, gtk3-3.24-41, Xorg, DMZ-Vanilla (=DMZ-White) cursor theme from FreeBSD's cursor-dmz-theme-0.4.5 package. It is NOT observed on a virtual Debian 12.5 machine with identical packages, installed with default configuration. It IS observed when running Firefox 123 on the physical machine in a new and clean account with nothing else configured than the cursor theme.

Distro: Linux Mint 21.3
Desktop: Xfce 4.18
Display server: Xorg
GTK: libgtk-3-0, version: 3.24.33-1ubuntu2 (lsof | grep firefox | grep libgtk- shows /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.29)
Cursor: Redglass (but can reproduce with DMZ too)
Type of firefox: 123.0+linuxmint1+virginia (from a deb package)
The issue is also present when running the binary build from firefox.com (unpacked into /opt).

Messages when launching firefox from the command line:

[Parent 3609, Main Thread] WARNING: Theme parsing error: gtk.css:3:2: Junk at end of value for color: 'glib warning', file /builds/worker/checkouts/gecko/toolkit/xre/nsSigHandlers.cpp:187

(firefox:3609): Gtk-WARNING **: 11:31:31.991: Theme parsing error: gtk.css:3:2: Junk at end of value for color
ATTENTION: default value of option mesa_glthread overridden by environment.

The theme-parsing error is produced by other GTK apps too, but there the cursor is fine (redglass).

See Also: → 1884566
Assignee: nobody → stransky
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
See Also: → 1880260
Flags: needinfo?(stransky)
Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/db5832c0ca43 [Linux] Allow to use legacy cursor if widget.gtk.legacy-cursors.enabled is set r=emilio
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 125 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: