1233868 - [GTK 3.18] zoom-in / zoom-out cursors aren't displayed

Status: RESOLVED INVALID

(Core :: Widget: Gtk, defect)

Description

[Alexis]

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

Steps to reproduce:

I use latest stable Firefox packaged for Archlinux (43.0.1).




Actual results:

When the cursor move over a css element with cursor:zoom-in; or cursor:zoom-out; property, cursor doesn't change.

You can try here : https://developer.mozilla.org/en-US/docs/Web/CSS/cursor


Expected results:

Default cursor is supposed to change to zoom-in/out to indicates that something can be zoomed in or out.

Comment 1

[Mats Palmgren (inactive)]

Can you reproduce the problem also with the Mozilla build?
https://archive.mozilla.org/pub/firefox/releases/43.0.1/linux-x86_64/en-US/firefox-43.0.1.tar.bz2

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Works fine for me using debug nightly on Ubuntu 15.10.

Comment 3

[Alexis]

(In reply to Mats Palmgren (:mats) from comment #1)
> Can you reproduce the problem also with the Mozilla build?
> https://archive.mozilla.org/pub/firefox/releases/43.0.1/linux-x86_64/en-US/
> firefox-43.0.1.tar.bz2

No... (it works).

Comment 4

[Mats Palmgren (inactive)]

OK, thanks.  Sounds like the problem is in the Archlinux build only then.
Perhaps they used some unsupported combination of build options?

Can you start the Archlinux Firefox again and load about:buildconfig
in the URL bar and copy-paste the info here please?

Comment 5

[Alexis]

Build platform
target
x86_64-unknown-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
gcc 	5.3.0 	-Wall -Wempty-body -Wpointer-to-int-cast -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -std=gnu99 -fgnu89-inline -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe
c++ 	5.3.0 	-D_FORTIFY_SOURCE=2 -Wall -Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -fprofile-use -fprofile-correction -Wcoverage-mismatch -O3 -fomit-frame-pointer -D_FORTIFY_SOURCE=2

Configure arguments

--enable-application=browser --prefix=/usr --libdir=/usr/lib --enable-release --enable-gold --enable-pie --enable-official-branding --enable-default-toolkit=cairo-gtk3 --with-system-nspr --with-system-nss --with-system-jpeg --with-system-zlib --with-system-bz2 --with-system-png --with-system-libevent --with-system-libvpx --with-system-icu --enable-system-hunspell --enable-system-sqlite --enable-system-ffi --enable-system-pixman --enable-startup-notification --enable-pulseaudio --enable-gstreamer=1.0 --disable-crashreporter --disable-updater --disable-installer --disable-debug-symbols --with-google-api-keyfile=/build/firefox/src/firefox-43.0.1/google-api-key --with-google-oauth-api-keyfile=/build/firefox/src/firefox-43.0.1/google-oauth-api-key --with-mozilla-api-keyfile=/build/firefox/src/firefox-43.0.1/mozilla-api-key

Comment 6

[Mats Palmgren (inactive)]

I'm guessing it's the "--enable-default-toolkit=cairo-gtk3" that causes the problem.

Comment 7

[Evangelos Foutras]

Indeed, this appears to affect GTK3 builds only (which is the case for our Arch Linux Firefox 43 package).

My understanding is that the GTK3 port was ready to ship in Firefox 43 and it was only delayed until Firefox 45 to ensure a smooth upgrade for people who might not have GTK3 installed.

Comment 8

[Karl Tomlinson (:karlt)]

GTK3 builds show these cursors here (Gentoo) and in comment 2, so there must be some other factor involved.

Comment 9

[Evangelos Foutras]

The issue was introduced by the following commit in GTK+ 3.17.2 and later:

    commit 17cd3c321838dc3d67c3588956d1e4d68ca70df3
    Author: Matthias Clasen <[e-mail]>
    Date:   Fri May 8 09:37:39 2015 -0400

        X11: Make css cursor names work

        Map css cursor names to traditional X cursor names to increase
        our chance of finding a good cursor in the cursor theme.

I'm not sure if it's a bug in GTK or Firefox. :)

[1] https://git.gnome.org/browse/gtk+/commit/?id=17cd3c321838dc3d67c3588956d1e4d68ca70df3

Comment 10

[Evangelos Foutras]

@Matthias Halp!

Comment 11

[Evangelos Foutras]

After some more poking around, it seems to me that the following occurs when Firefox wants to display, for example, a zoom-in cursor:

1) get_gtk_cursor() gets called with eCursor_zoom_in as its argument.
2) Firefox attempts to create "a named cursor based on the hash of our custom bitmap, as libXcursor has some magic to convert bitmapped cursors to themed cursors" (quoting from a comment in nsWindow.cpp).
3) Firefox calls gdk_cursor_new_from_name() passing the hash "f41c0e382c94c0958e07017e42b00462" as the icon name.
4) (I'm assuming) the hash lookup trick doesn't work and GTK's new name_fallback() function loads a "left_ptr" cursor instead.
5) Whereas previously GTK would return NULL, now it returns the default pointer icon and Firefox no longer proceeds to load its own bitmap from nsGtkCursors.h.

I can see the why the name fallback was added in GTK but apparently it tries too hard not to return NULL (which in this case is expected/desired).

(Retracting my needinfo request; I used it hastily and most likely incorrectly. If this is considered to be a GTK bug, it should probably be reported to the GNOME bugzilla instead of pinging Matthias here; my bad!)

Comment 12

[Evangelos Foutras]

Also reported to GNOME's bug tracker at https://bugzilla.gnome.org/show_bug.cgi?id=760141

Comment 13

[Evangelos Foutras]

(In reply to Evangelos Foutras from comment #12)
> Also reported to GNOME's bug tracker at
> https://bugzilla.gnome.org/show_bug.cgi?id=760141

That bug is now resolved and the fix should be in the upcoming GTK 3.18.7.