Bug 114490

I can't follow how cursor themes can be influenced by Firefox. So moving to
gnome-maintainers for checking.

I can confirm this but within Firefox itself nothing changed IMHO.
So this might be a GTK "feature"?

Could someone please comment on this?

Only over the Firefox window the cursor is the ugly default X-Window theme (the
black cursor).  I tried running Gimp (as GTK application) and it does not have
that problem.

You're right. But the very same package compiled on 9.3 running on 9.3 doesn't
show this behaviour. So nothing Firefox code specific is involved here IMHO.

Could be related to the yast2 changes for bug 74309.

Adding kde-maintainers too since it occurs there as well.

Mozilla just uses standard GTK calls to set the cursor: gdk_window_set_cursor. I
have no idea what could cause that to not use the theme. Maybe a GTK person can
give us a clue...

the cursor passed to gdk_window_set_cursor is obtained by gdk_cursor_new.

I used gdb to verify that XCreateFontCursor is being called with type
XC_sb_h_double_arrow. That ends up bypassing the Xcursor theme code ecause
Xcursor thinks there is no cursor theme.

So why's that? Initially Xcursor has the right theme ("crystalwhite" on this
box). It gets that by calling XGetDefault(dpy, "Xcursor", "theme_core"). But
later Mozilla calls gtk_settings_get_default(). This call creates a new settings
object, calls gtk_rc_reparse_all_for_settings which I assume parses various
gtkrc's, and then calls settings_update_cursor_theme.
settings_update_cursor_theme tries to get the theme name by looking up the
gtk-cursor-theme-name in the settings, but it's not there, so it thinks there is
no theme *and sets it to NULL in Xcursor*. Net effect: calling
gtk_settings_get_default() has destroyed the Xcursor theme setting so from then
on all cursors are set to the default X cursors.

So I guess there are two problems:
1) GTK and Xcursor should agree on how the cursor theme name is configured.
2) In the interim gtk-cursor-theme-name should be set in some gtkrc. I'm not
sure how that works.

I tried to implement option 2 but I can't figure out how to get the setting to
apply.

The GTK settings code that reads the cursor theme setting and uses it to
override the Xcursor theme setting was added in mid-June, so that's why this bug
has appeared.

I'm not sure why other GNOME apps still work. Maybe they use
gdk_cursor_new_from_name, GIMP seems to set the Xcursor theme to NULL too, but
somehow it's not affected. Maybe it's already acquired all the cursors it needs
by the time it overrides the Xcursor theme.

Anyway, I'm a bit out of my depth here. Someone out there must know how to set
GTK settings properly and should be able to fix this. I added

gtk-cursor-theme-name = "crystalwhite"

to a fresh ~/.gtkrc-2.0 and it didn't work.

hmm, the gtk 2.8.3 release notes read:
* Fix problems with the handling of initial settings
  for font options and cursor themes [Frederic Crozat, 
  Joe Markus Clarke, Owen Taylor, Kjartan Maraas]

If the theme is chosen within the gnome-control-center it works.
So somehow GNOME/GTK doesn't inherit the X theme correctly IMHO. 
Another thing is that gtkrc-2.0 seems to be ignored.
Raise severity

Maybe we should make sure that gtk-cursor-theme is configured to some theme for
the release.

For the future it would be nice to have some GTK guy tell us which component is
doing wrong. GTK or Firefox. As other GTK applications don't have such a problem
it might be possible that Firefox doesn't use the "recommended" way for cursors.

Settings in your ~/.gtkrc-2.0 usually get overriden by the settings from
gnome-settings-daemon.

Anyway, the right solution is to figure out what is different in Firefox's
behavior.  Could someone trace GTK+'s initialization of cursors in both Firefox
and a non-problematic app?  See e.g. these changes:

2005-06-17  Matthias Clasen  <mclasen@redhat.com>

	* gdk/x11/gdkprivate-x11.h: 
	* gdk/x11/gdkcursor-x11.c: Handle cursor theme changes
	for cached cursors which are not associated with a window
	at the time of the theme change, by storing a serial
	number in each cursor, and updating the theme_serial 
	counter whenever the cursor theme changes.
	
	* gdk/x11/gdkcursor-x11.c (_gdk_x11_cursor_update_theme): 
	Private function to update a cursor to the current
	cursor theme if necessary.

	* gdk/x11/gdkmain-x11.c (gdk_pointer_grab): 
	* gdk/x11/gdkwindow-x11.c (gdk_window_set_cursor): Call
	_gdk_x11_cursor_update_theme() here.

*** Bug 115211 has been marked as a duplicate of this bug. ***

Aargh, I dropped off the CC list somehow.

Federico, see comment #8. It's pretty simple. Mozilla calls
gtk_settings_get_default(). GTK finds no setting for "gtk-cursor-theme-name", so
it tells Xcursor to use no theme, hence the bug.

I don't know why other GTK apps aren't affected but I think it's pretty clear
this is either a GTK bug or a bug in our configuration that we haven't set
gtk-cursor-theme-name anywhere.

Should I email Clasen and ask him how it's supposed to work?

I see at least two issues here:
1. my gtkrc-2.0 setting is ignored even if gnome-settings-daemon is not running
2. if there is no setting for gtk-cursor-theme-name anywhere GTK shouldn't
   overwrite the Xcursors

Andreas, it would be nice to have this fixed but we need help from GTK group here.

Looks like a gtk, problem. Trying pure gtk application gtk-demo (gtk2-devel),
with gnome-settings-daemon cursors are OK. Without it, default cursor is OK, but
other cursors are bad, too. In firefox, the default cursor is affected, because
it uses gtk function to set it to the default.

*** Bug 115122 has been marked as a duplicate of this bug. ***

Wait, does Firefox explicitly call gtk_settings_get_default()?  That's not
right.  It should be calling gtk_settings_get_for_screen().

I don't have beta4 yet, so I can't test this on my box.  Could you please
confirm what happens in these scenarios:

- GNOME session, run Firefox and a normal GTK+ app
- KDE session, run Firefox and a normal GTK+ app
- plain X server (with fvwm?), run Firefox and a normal GTK+ app

What I want to know is what happens if gnome-settings-daemon is not running. 
I'm not sure if a KDE session will set all the cursor-related XSETTINGS.

But it does not explain, why gtk-demo has bad cursors, too.

Yes, it calls gtk_settings_get_default()
see: http://lxr.mozilla.org/aviary101branch/search?string=gtk_settings_get_default
(no match for gtk_settings_get_for_screen)

I can't make your tests at the moment since I have only VNC access to a 10.0rc1
here.
But I'm pretty sure that someone else from the audience can give you the results.

See also https://bugs.freedesktop.org/show_bug.cgi?id=4244

It talks about the possibility of making XcursorSetTheme(dpy, NULL) set the
default theme, rather than no theme.

I'll take on this.

(In reply to comment #23)
> Wait, does Firefox explicitly call gtk_settings_get_default()?  That's not
> right.  It should be calling gtk_settings_get_for_screen().

gtk_settings_get_default() just calls gtk_settings_get_for_screen(), passing
gdk_screen_get_default(). And that's exactly what Firefox would do if we called
gtk_settings_get_for_screen(). Anyway gtk_settings_get_for_screen() is what
triggers this bug so this is a separate issue.

> - KDE session, run Firefox and a normal GTK+ app

Fails in both (Firefox and GIMP). I don't have a full beta4 install so I can't
test the others yet. It's tricky to test because cursors acquired before the
first gtk_settings_get_for_screen() call are correct ... so as Stanislav said,
in lots of GTK apps, at least the default cursor looks right, and maybe others
too if the app acquires them at startup. That's why I thought other GTK apps
were working. But if you start GIMP, create a document, and choose the "move
layers and selections" tool, you get the default X left-pointing hand cursor.

Created attachment 49406 [details]
gtk+-default-cursor.patch

Patch for gtk2. This patch fixes gtk-demo, but not firefox.

I am not sure, whether it is correct (e. g. if it works, if you want to reset
theme.

Alternative could be:

if (!theme)
  theme = g_getenv ("XCURSOR_THEME");

About comment #29 - I'd rather fix it in Xcursor itself, as per comment #26, if
it turns out that that's the real bug.

I'm downloading the xorg-x11 sources to see just how Xcursor operates.  I have
no idea what its defaults are, or if the defaults are even configurable. 
Doesn't the X server always start up with the default/ugly cursors, and you
always need to do XcursorSetTheme("foo") to load a pretty set of cursors?

Looks like you can set a default cursor theme by sticking this in your
/etc/X11/Xresources:

  Xcursor.theme: theme_name
  Xcursor.size: some_size

So probably the XcursorSetTheme(dpy, NULL) is about resetting to *that*, instead
of to the ugly cursors.

FWIW I agree.

Stefan, does this make sense? Can we populate /etc/X11/Xresources with the
cursor theme in /etc/sysconfig/windowmanager?

Looks like the wrong approach to me. AFAIK the according XCURSOR environment 
variables should be set and used instead. 

Who can/will change this?

Probably the GNOME/KDE session startup.

See comment #8. Xcursor *is* getting the default theme correctly from X
resources. That code just needs to be used again to re-get the default theme
when XcursorSetTheme(NULL) is called.

Created attachment 49604 [details]
XcursorSetTheme-default-cursor.patch

Proposed patch for xorg-x11. Not yet tested. I will report result later.

Created attachment 49612 [details]
XcursorSetTheme-default-cursor.patch

Typo fix.

I'm using a slightly different patch; will attach it in a second.

Package rebuilt and tested: My XcursorSetTheme-default-cursor.patch fixes
gtk-demo cursors, but firefox still uses default cursor.

FWIW, gaim and xchat also suffer from this problem.  And it's not all cursors 
that are messed up.  What I'm seeing is that only the text cursor and the 
hyperlink cursor are messed up--defaulting to the ugly core cursors.

Created attachment 49650 [details]
xorg-x11-114490-xcursor-reset-theme-name.diff

This patch seems to give me correct cursors in all applications.  I've
submitted it upstream to see what the maintainer says.

To summarize:

1. The XCURSOR_* environment variables take precedence over the Xcursor.*
xresources.

2. We only set the env. vars.; that's correct behavior.

3. The patch makes the Xcursor library fall back to the configuration values
(env. vars. or Xresources) if you call XcursorSetTheme(dpy, NULL).

Egbert, Matthias, Stefan, is the patch in #43 correct?

I'm not completely fluently in libXcursor, but the patch seems to be good.

It changes a structure size in xcursorint.h, but as this is internal it should
change the ABI. Correct?

Some things are a bit cumbersome (malloc + strcpy instead of strdup), but so is
the original code, so this perfectly matches the original code.

Stefan, please apply and create a package for testing.

Read that: it *shouldn't* change the ABI...

KeithP reviewed my patch and committed it upstream, so perhaps it's good for our
package as well :)

My feelings are somewhat mixed. I would like to hear a comment by Egbert first,
before I want to submit a package which applies this patch. A build for testing
is currently running.

You can find packages for testing here:  
  
~sndirsch/pkgs: 
xorg-x11-libs-6.8.2-99.i586.rpm   
xorg-x11-libs-6.8.2-99.x86_64.rpm 
xorg-x11-libs-6.8.2-99.ppc.rpm 
 

The patch looks OK. It's rather trivial.

But I wonder why Keith didn't want to submit it to X.Org CVS (yet).

"I've committed Federico's patch to xlibs/Xcursor, but not to xorg/lib/Xcursor.
 For that, I believe we need to push it through the release queue."

JFYI, xlibs tree isn't used by anyone ...

Anyway, we need test results first!

FYI: Works in RC2.

Interesting. The X11 patch isn't applied for RC2. So this means we don't need it
at all?

Okay, this is embarrassing, but my mistake:

It does *not* work in RC2.  Update just didn't touch the patched package and I
didn't see it at once because the version and build number is the same.

Sorry for the confusion!

Ok. Did you try my new patched packages mentioned in comment #50?

Yes, I did.  With the patches packages it works for me.  Minor glitch with QT
windows when moving the cursur over the "dashed" resize area.  As soon as you
reach the window border or go back into the window itself, the cursor works again.

Dennis: what's that glitch in Qt windows?  Is that on a KDE or GNOME session?

Frederico,

I can't take a screenshot of the cursor, but a screenshot of the affected area
is attached.  It only seems to happen with unthemed QT applications, so I'n not
sure whom to blame in this case :-)

Created attachment 49901 [details]
Wrong cursor shown in unthemes QT app

Dennis: is that a Qt app on a KDE or a GNOME session?  Which cursor do you get
in the drag area?

Sorry, it's a GNOME session.  I get the standard X cursor looking like the one 
I will attach in a second.

Created attachment 49922 [details]
Cursor I get when moving the cursor over area shown in attachment 49901 [details]

New xorg-x11 package with the patch applied has now been submitted for 10.0 and
STABLE. Reassigning to Frederico for further investigation.

Andreas, could you create a SWAMP entry for this?

Description: 
- fixes cursor theme in Firefox (#114490)

Maintenance-Tracker-2489

Prior to this update my whole GNOME session and GTK apps were using the
incorrect cursors. Not only Firefox.

*** Bug 120946 has been marked as a duplicate of this bug. ***

I just installed stable sl10.0-gm and I found this has not been fixed. 
 
Is there any workaround/patch? 

An update via YOU will be available soon (xorg-x11-libs). 

released

Not everything's fixed with that patch though - when placing the mouse cursor over a flash animation within the browser, there's still the old X11 hand.

*** Bug 127751 has been marked as a duplicate of this bug. ***

Since the bug is not 100% fixed (old cursor theme's still present when you hover over flash animations), I'm reopening the bug.

the flash cursor is not the "old X11 hand", it's a custom cursor of flash. And as you might know it's binary only.

You're right, I've just had a look at it in Suse 9.3.