314224 - GTK+ embed cursor always overrides global X11 cursor

Status: RESOLVED INACTIVE

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

Description

[Christian Neumair]

User-Agent:       Mozilla/5.0 (X11; U; Linux ppc; de-DE; rv:1.7.12) Gecko/20051010 Epiphany/1.8.2 (Ubuntu) (Ubuntu package 1.0.7)
Build Identifier: Mozilla/5.0 (X11; U; Linux ppc; de-DE; rv:1.7.12) Gecko/20051010 Epiphany/1.8.2 (Ubuntu) (Ubuntu package 1.0.7)

I was unable to find this particular issue in the 200 cursor-related bugs, but it might already be reported.

When using X11/GNOME/Epiphany, and launching an application, the global X11 cursor changes to a busy cursor. However, for the embedded widget, this cursor is overridden, since gdk_window_set_cursor is called with GDK_LEFT_PTR. Applications are meant to call gdk_window_set_cursor (window, NULL); whenever they don't provide any particular cursor.

The relevant code is in widget/src/gtk2/nsWindow.cpp, nsWindow::SetCursor and get_gtk_cursor. eCursor_standard should be traversed into a NULL GdkCursor, and not into GDK_LEFT_PTR.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Christian Neumair]

Attachment: Proposed patch (untested, compiles)

Comment 2

[Christian Neumair]

Attachment: Proposed patch #2

Christian Persch felt good enough to test my first patch. This one should work :).

Comment 3

[Christian Neumair]

I've just noted that attachment 201168 [details] [diff] [review] swaps the assignment of mCursor and the mContainer check. I have no clue whether this has any visible effects.

Comment 4

[Christian Neumair]

Attachment: Proposed patch #3

From IRC:
21:06:54 <chpe> Manny: I think the ordering is important, so that (when) mContainer is created, it can set the right cursor
21:07:32 <Manny> chpe, (when) it is created, why should it be NULL?
21:09:15 <chpe> it's NULL, but later (...) the container is created, and when that's done, it should have the right cursor
21:11:42 <Manny> I'm not sure whether I can support this, since the cursor won't be actually set in either case, and a later aCursor != mCursor check might fail although nothing was actually done. However, I don't want to break the old semantics, and will adapt it.

Comment 5

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1552613

Comment 6

[Sylvestre Ledru [:Sylvestre]]

no activity for years, closing.
Feel free to reopen if this is still occurring