1812698 - window manager decoration disappeared

Status: RESOLVED FIXED

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

Description

[Peter Gervai]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0

Steps to reproduce:

Upgraded nightly to 2023-01-26.

Actual results:

The window manager borders and icons disappeared and FF has its own style invisible border.

Expected results:

There should be the Window Manager borders with buttons and stuff.

Comment 1

[Peter Gervai]

The actual change may have been for yesterday's update, since the browser wasn't promptly restarted (but rather crashed by microsoft teams, but let's not sidetrack).

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 3

[Martin Stránský [:stransky] (ni? me)]

Can you please try mozregression tool to check which commit caused it?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.

Comment 4

[Peter Gervai]

4:25.83 INFO: Last good revision: 7904cd90621f402e7bfd66e7101372ab45cc8ffd
4:25.83 INFO: First bad revision: 52fa6a56b687c22c119bcce966caae5806f50b5a
4:25.83 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7904cd90621f402e7bfd66e7101372ab45cc8ffd&tochange=52fa6a56b687c22c119bcce966caae5806f50b5a

Comment 5

[Peter Gervai]

The environment is xfce4/xfwm4 on xorg (altogether Debian/sid).

Comment 6

[Martin Stránský [:stransky] (ni? me)]

Emilo, any idea? Thanks.

Comment 7

[Simon McFarlane]

Sway users are also affected by this change; I'm seeing a large, empty, client-side title bar that seemingly can't be disabled.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Attachment: sway-nightly

Can you elaborate? What are you seeing? This is what I see on Sway with latest nightly (the only difference should be the close button, and you can remove it checking the "Title Bar" button on customize mode)

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Looks pretty similar to what I see on release (modulo the close button again)

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Attachment: XFCE-nightly-with-titlebar

The patch that regressed this just switched the default behavior but you can get the window decorations back by checking the "titlebar" checkbox as shown above.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Attachment: XFCE-nightly-default

This is the default behavior on xfce4 for me, does that match what you see? If so I'd say this is intended, the patch that changed behavior made our behavior consistent across desktop environments, but you can still restore the old behavior as described above.

Comment 12

[Peter Gervai]

Attachment: flame_2023-01-30_00-50.png

On the left a reference window with decoration, header, borders.
On the right Firefox with no icons, no header, no borders.

Comment 13

[Peter Gervai]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #10)

Created attachment 9314769 [details]
XFCE-nightly-with-titlebar

The patch that regressed this just switched the default behavior but you can get the window decorations back by checking the "titlebar" checkbox as shown above.

Hmm. "Switched the default behaviour" means:

• broke the window decorations,header, border, and a lot of functionalities based on these
• without any notification or offered remedies
• resettable in a place I was not able to find in more than 1 hour (and right now it required about 5 minutes to identify based on your screenshot).

And indeed, after finding that setting it could be reset to the original state. I can send the window to the back again... yay.

I would say this is a highly intrusive change. Also it is not resettable in the obvious places (settings/view? themes?) or even the non-obvious ones (tryed to look up "decor" and "window" and "border" and a lot else in settings and about:config).

I don't think this should be changed without user knowledge and active agreement.

Comment 14

[Simon McFarlane]

Emilio, your sway screenshot matches what I see. I think the CSD titlebar just bulkier than the old non-CSD tab bar, at least on sway. Hilariously, because sway doesn't apply any window decorations (at least in my config), the "title bar" checkbox does the opposite of what I think it would do: checking it makes the title bar disappear, while un-checking it brings it back.

Comment 15

[Paul Bone [:pbone]]

I can confirm my title bar is missing since Bug 1812289. But I just noticed the buttons are now on the right in the line of tabs. But it took me half the day to find the buttons (looks like the xfce screenshot in comment 11). This caused me some confusion because things like this are sometimes hard for me to notice and find on the screen - I have poor eyesight. So although this is intentional change, I'd like to provide some feedback to be weighed against the benefits of this change:

• it's the kind of change that could cause confusion for some users, either with low vision or who had become accustomed to the previous layout.
• Some functionality is accessed by right-clicking on the title bar, the area for those clicks is now smaller and more difficult to click - equally difficult as the close/minimise/maximise buttons are.
• it's different from (almost?) every other application on my computer. I expect more programs to have a similar look and feel on the same OS rather than having to learn new patterns/behaviours for different programs on the same computer.

I'm using LInux Mint 21 and 20.3 (reproduced on two PCs) with the Cinnamon desktop. The title bar is missing from every window, it's missing in both the "normal" and "maximised" state.

Thanks.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1812289

Comment 17

[Emilio Cobos Álvarez (:emilio)]

(In reply to Paul Bone [:pbone] from comment #15)

I can confirm my title bar is missing since Bug 1812289. But I just noticed the buttons are now on the right in the line of tabs. But it took me half the day to find the buttons (looks like the xfce screenshot in comment 11). This caused me some confusion because things like this are sometimes hard for me to notice and find on the screen - I have poor eyesight. So although this is intentional change, I'd like to provide some feedback to be weighed against the benefits of this change:

• it's the kind of change that could cause confusion for some users, either with low vision or who had become accustomed to the previous layout.

That's fair. However this is the default Firefox behavior in every other platform (windows / macOS have done that by default since forever).

• Some functionality is accessed by right-clicking on the title bar, the area for those clicks is now smaller and more difficult to click - equally difficult as the close/minimise/maximise buttons are.

Right-clicking in the titlebar should show the native menu, see bug 1771950.

• it's different from (almost?) every other application on my computer. I expect more programs to have a similar look and feel on the same OS rather than having to learn new patterns/behaviours for different programs on the same computer.

That also really applies to other DEs but the GNOME default was for a long time drawing on the titlebar...

As for possible paths forward we could:

• Back out the patch and restore the previous default; Document it as an intentional default pointing to this bug. It's a bit weird to have different defaults for different desktop environments that are capable of doing CSD, but maybe it's ok.
• Write a migration to avoid changing behavior in existing profiles, but keep the new default for new profiles.
• Maybe something else I'm not thinking of?

I think I'd prefer the second option, if only because it brings (long term) consistency across DEs that support CSD at least... Thoughts Martin?

Comment 18

[Peter Gervai]

• Some functionality is accessed by right-clicking on the title bar, the area for those clicks is now smaller and more difficult to click - equally difficult as the close/minimise/maximise buttons are.

Right-clicking in the titlebar should show the native menu, see bug 1771950.

However I have completely lost the ability to send firefox window in the background (which I do a_lot), since it is bound to mouse-action and not on the native menu (apart from that functions triggered by one click versus click+move to menu and select+click does make a difference).
I also have lost the titlebar text which I rely on finding underlying windows...

Write a migration to avoid changing behavior in existing profiles, but keep the new default for new profiles.

I agree, I also would suggest some way to make it changeable (and searchable) in the settings too, since I believe that's the first logical place people start looking for it.

Comment 19

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1812698 - Migrate old linux profiles to preserve titlebar default. r=Gijs,mak,stransky

Comment 20

[Gian-Carlo Pascutto [:gcp]]

Back out the patch and restore the previous default; Document it as an intentional default pointing to this bug. It's a bit weird to have different defaults for different desktop environments that are capable of doing CSD, but maybe it's ok.

I suspect we need at least a round of bugfixing before we default enable, see for example bug 1813554. Note that although it took me a day to notice (sorry, I'm the one that said it worked fine on KDE!), it's pretty fatal breakage.

Comment 21

[Gian-Carlo Pascutto [:gcp]]

This caused me some confusion because things like this are sometimes hard for me to notice and find on the screen - I have poor eyesight. So although this is intentional change

I'm not sure, I think this is another bug: it looks like the resize/maximize buttons in Firefox don't respect display scaling (which I suspect you, like me, use because my eyesight isn't great either...). Filing this one as well.

Comment 22

[Gian-Carlo Pascutto [:gcp]]

it looks like the resize/maximize buttons in Firefox don't respect display scaling

Filed that as bug 1813697.

Comment 23

[Paul Bone [:pbone]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #17)

(In reply to Paul Bone [:pbone] from comment #15)

I can confirm my title bar is missing since Bug 1812289. But I just noticed the buttons are now on the right in the line of tabs. But it took me half the day to find the buttons (looks like the xfce screenshot in comment 11). This caused me some confusion because things like this are sometimes hard for me to notice and find on the screen - I have poor eyesight. So although this is intentional change, I'd like to provide some feedback to be weighed against the benefits of this change:

• it's the kind of change that could cause confusion for some users, either with low vision or who had become accustomed to the previous layout.

That's fair. However this is the default Firefox behavior in every other platform (windows / macOS have done that by default since forever).

Yeah, I understand. I think I've seen it on Windows but I didn't notice on MacOS, I just checked, More MacOS apps draw in their title bar area so I hadn't noticed it. I think my "surprise" comes from it being "a change" and different from many other apps on Cinnamon.

• Some functionality is accessed by right-clicking on the title bar, the area for those clicks is now smaller and more difficult to click - equally difficult as the close/minimise/maximise buttons are.

Right-clicking in the titlebar should show the native menu, see bug 1771950.

Yeah, I can find that, I just have to click the area all the way to the right because I have many tabs.

• it's different from (almost?) every other application on my computer. I expect more programs to have a similar look and feel on the same OS rather than having to learn new patterns/behaviours for different programs on the same computer.

That also really applies to other DEs but the GNOME default was for a long time drawing on the titlebar...

As for possible paths forward we could:

• Back out the patch and restore the previous default; Document it as an intentional default pointing to this bug. It's a bit weird to have different defaults for different desktop environments that are capable of doing CSD, but maybe it's ok.
• Write a migration to avoid changing behavior in existing profiles, but keep the new default for new profiles.
• Maybe something else I'm not thinking of?

I think I'd prefer the second option, if only because it brings (long term) consistency across DEs that support CSD at least... Thoughts Martin?

I also like #2. If you were to back out the patch then that would mean Firefox would behave differently on different DEs, which seems more odd than differently on different OSs.

Would #1 or #2 have the problem that we must maintain codepaths for CSD and non-CSD?

My preferred option would be if DEs had a global option that apps like Firefox could check, like some do for dark/light mode. So that when I'm picking my desktop theme/window decorations/etc I can also choose if I want to enable this and that more (but probably not all) apps change their behaviour. I don't see an option for that in Linux Mint's settings though.

Thanks for considering my feedback Emilio.

Comment 24

[Martin Stránský [:stransky] (ni? me)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #17)

• Write a migration to avoid changing behavior in existing profiles, but keep the new default for new profiles.

Looks ok to me.

Comment 25

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1812698 - Expose desktopEnvironment via nsIXULRuntime rather than nsIGfxInfo. r=stransky,#gfx-reviewers

This is:

• An easier way for browser code to access it.
• Avoids having a bunch of per-platform implementations.
• We don't need to actually get graphics info for it to work.

So it should be a bit nicer over all.

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4843b1cd5e11
Expose desktopEnvironment via nsIXULRuntime rather than nsIGfxInfo. r=stransky
https://hg.mozilla.org/integration/autoland/rev/e28f327fe158
Migrate old linux profiles to preserve titlebar default. r=mak,stransky

Comment 27

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/4843b1cd5e11
https://hg.mozilla.org/mozilla-central/rev/e28f327fe158

Comment 28

[Daniel Bodea [:danibodea]]

This issue appears not to reproduce on Ubuntu 22 with gnome desktop environment (default) with Nightly v111.0a1 from 2023-01-26.
Which desktop environments are supposed to reproduce this issue and which ones should be verified to confirm this fix?

Thanks!

Comment 29

[Emilio Cobos Álvarez (:emilio)]

XFCE, KDE, or basically anything that wasn't GNOME.

Comment 30

[Daniel Bodea [:danibodea]]

We don't officially have systems that aren't gnome, so we can't reproduce, nor verify this fix. This being considered, I will remove the qe+ flag.