969322 - :-moz-window-inactive triggers on window drag

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Svitozar Cherepii]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140205004602

Steps to reproduce:

Style something with :-moz-window-inactive


Actual results:

:-moz-window-inactive triggers on window drag


Expected results:

Nothing should change.

Comment 1

[Aleksandr Seleznev]

Usage "focus_out_event" gtk+ signal for detecting window state changes is
uncorrect solution. "window_state_event" signal + GDK_WINDOW_STATE_FOCUSED
should works better, but it's GTK3-only feature.

References:

1. https://mxr.mozilla.org/mozilla-central/source/widget/gtk/nsWindow.cpp

2. https://developer.gnome.org/gdk2/stable/gdk2-Event-Structures.html#GdkWindowState

3. https://developer.gnome.org/gdk3/stable/gdk3-Event-Structures.html#GdkWindowState

Comment 2

[Jim Mason]

Attachment: Bug 969322 - :-moz-window-inactive triggers on window drag - r?karlt

This is an old issue, but it's still causing problems.

It is the root cause of Bug 1491808 (Titlebar looks inactive when the main windows is dragged). The fix for 1491808 works around the issue, but is not a definitive solution. Csd titlebar issues remain; for example: https://github.com/rafaelmardojai/firefox-gnome-theme/issues/22.

The problem is that focus in/out events as delivered by gtk do not conceptually correspond to the meaning of focus in/out as expected by gecko. This is irrespective of wm/compositor, and it is not Wayland-specific. I am seeing this under X11 and compiz, for example. This fix decouples gecko from gtk focus in/out events and instead synthesizes focus in/out based on changes to window_state_event GDK_WINDOW_STATE_FOCUSED, as suggested by Aleksandr Seleznev.

The attached patch does the following:

• reverts the changes for Bug 1491808
• decouples gtk's focus in/out events from gecko
• synthesizes focus in/out events in response to changes in GDK_WINDOW_STATE_FOCUSED
• synthesizes focus in events upon restore from iconic state

The change is conceptually simple, but the condition is made a little more complex because of the inclusion of focus in upon restoration from iconic state.

As the patch resolves the root cause, the changes in support of Bug 1491808 are no longer necessary and have been removed.

Caution: I made and tested these changes against the esr branch. The underlying code on central has had subsequent changes which may affect the behaviour. Also, I have limited environments to test, and this needs to be tested well for regressions.

Thanks for considering the patch. I hope it is helpful.

Comment 3

[Karl Tomlinson (:karlt)]

https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-window-inactive does not define "inactive window", but the mention of "different styles to background windows" suggests that "inactive" may mean "not background".

It would seem reasonable to me to align :-moz-window-inactive with GDK_WINDOW_STATE_FOCUSED/_NET_WM_STATE_FOCUSED for "whether the window's decorations are drawn in an active state".

The best description I've found for the difference between _NET_WM_STATE_FOCUSED and the keyboard focus window is https://mail.gnome.org/archives/wm-spec-list/2011-October/msg00005.html

The behavior on window dragging actually depends on whether the window manager grabs the keyboard focus or not. For example, with kwin window drags, :-moz-window-inactive does not match.

Comment 4

[Karl Tomlinson (:karlt)]

Something to be aware of is that https://gitlab.gnome.org/GNOME/gtk/commit/95648fd1942651ea1ca9aab9b7aa79df6f843f40 suggests that GDK_WINDOW_STATE_FOCUSED will always be set on window managers that don't support _NET_WM_STATE_FOCUSED, and this was observed in https://bugzilla.mozilla.org/show_bug.cgi?id=1170342#c3

That may be acceptable if only :-moz-window-inactive would depend on GDK_WINDOW_STATE_FOCUSED, but we would need some sort of fallback if keyboard focus indicators depended on this.

Comment 5

[Jim Mason]

Attachment: Bug 969322 - make :-moz-window-inactive state follow GDK_WINDOW_STATE_FOCUSED when drawing in titlebar

This patch fixes activation of the :-moz-window-inactive pseudoclass
in client side decoration during drag operations. It depends on and
complements the fixes provided in support of Bug 1491808.

Obsoletes D50445

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b5e88a86b165
make :-moz-window-inactive state follow GDK_WINDOW_STATE_FOCUSED when drawing in titlebar r=karlt,stransky

Comment 7

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/b5e88a86b165

Comment 8

[Manuel Grießmayr]

I still have this issue on Linux/X11.

When I drag the main window of Thunderbird in version 102, then text in the menu bar changes its color but shouldn't. There is also a similar issue with the download list items in the download window of Firefox 102. I am on Xubuntu 22.04/X11.

When write in userChrome.css for Thunderbird:
menubar > menu:-moz-window-inactive {
color: red !important;
}

Then the text of the menu bar changes to red but not only when the window is inactive but also on drag. So the -moz-window-inactive seems to get triggered even on drag.

Can we reopen this issue?

See also Bug 1497534

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Please file a new bug rather than reopening a bug that was fixed by a patch. I can't repro this on Wayland, for the record.