1825137 - Collaboration problem between FF and KDE/Plasma window manager : resize of window not possible any more

Status: UNCONFIRMED

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

Description

[[:ChBe][e-mail]]

Attachment: Grab_border_problem.png

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

Steps to reproduce:

I did nothing !
No, seriously, problems with UI began to appear 5 or 10 versions back, I can't tell exactly since I was already used to the same bug with Google Chrome. Please, stop copying their bad habits ...

The latest and more serious problem just appeared today or yesterday.
Context :

• OS : stable Devuan 4 (chimaera), kernel 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux

• desktop environment : KDE/Plasma (kde-plasma-desktop 5:111; plasma-desktop 4:5.20.5-4)

• windows handling specific configuration : "Focus follow mouse". It's just a guess that it may have an influence on the problem

• Firefox : I'm not using the Devuan packaged version, I'm using the binary one from the Mozilla site. It's up to date, to the latest version : 111.0.1 (64-bit)

• GPU : nVidia RTX 3090. I first noticed the latest bug while using the NVIDIA-Linux-x86_64-525.60.11.run drivers. I updated today to the NVIDIA-Linux-x86_64-525.89.02.run version, but that did not solved anything.

• I tried to disable any compositing graphical effects (wobbly windows, exploding windows when closed, etc). Not sure that I found all the related settings, but anyway, no result at all.

• I'm French (may be you already noticed !) but I prefer to have everything configured in English : OS, KDE/Plasma, Firefox and other applications. Feel free to ask if I made language mistake, if things are no as clear and as English as they should be !

Actual results:

To understand the problem, you have to be familiar with the "Focus follow mouse" mechanisms. Especially, the fact that I don't have to click and put a window to the first plane to interact with it. I just have to put the mouse cursor over it, no click, and then, the window gets the focus and I can interact with it (click buttons, input text, etc).

Obviously, I can bring a window to the first plane when I want by clicking on one of its UI / window manager decoration (most often, the title bar, but also the resize borders)

Here come the first problem that appeared 5 or 10 versions back : clicking on the title bar doesn't not bring the Firefox window the first plane any more. The only solution left is <ALT> + <TAB>. Except for Google Chrome which displays the same annoying behavior since months if not years, all other software windows are perfectly going to the first plane doing that. Only Chrome and Firefox now are refusing to get to the first plane.

And yesterday or today appeared the new bug : there's no resize border any more. I cannot grab and resize Firefox windows. In addition, they now have a strange look : a grey, inactive border that doesn't react to clicks. See attached picture please

Expected results:

Well, the obvious : Firefox shall behave like any other application window, even when my desktop environment is configured with "Focus follow mouse" (if the problem is linked to that configuration).

I should be able to grab the resize border of any window, and to bring Firefox the the first plane when I want by clicking by any of its decoration / window manager element.

Comment 1

[[:ChBe][e-mail]]

I just tried to go back to "Click to focus" : this solves the problem of getting the window to the first plane.
This is not solving the missing resize handle problem
Sorry, I should have tried before posting the report few seconds before.

Comment 2

[[:ChBe][e-mail]]

Holy sh^Wcow, replying to myself again, the missing resize handle just disappeared. I'm a coder myself, so I don't like the word, but I'll make an exception : magically !
Tell me : is it possible that Firefox considers that a window is full screen, but while it is not actually full screen ?
Anyway, the "not going to the first plane bug" is still there.

Comment 3

[[:ChBe][e-mail]]

Replying to myself again because I get the problem back again.
Since last time, in short : back to my "Focus follow mouse" because I love it + a reboot.
Again, no way to grab resize handles.
This time, I can confirm that, although the window was not full screen, FF was ignoring grab handles like it was full screen.
I double clicked on the title bar to put it in full screen for real.
Then I moved the window (grab and drag the title bar).
Then resize handle went bask to life !

My I suggest (again ?) that you let the window manager decorate the FF window so that it is fully integrated in the current desktop environment ? Or at least, give us an option to get rid of nice but useless and annoying work of re-coding things that already exist ? Thanks !...

Comment 4

[BugBot [:suhaib / :marco]]

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 5

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

Do I understand correctly it's a KDE specific feature, right?

Can you use mozregression tool to find broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.

Comment 6

[[:ChBe][e-mail]]

Thank for following this problem.

I cannot tell if "Focus follow mouse" is a KDE specific feature. I hope not, it's so useful when you get used to it. I've been using KDE/Plasma for decades, and this feature for about half of that period.
I can provide a screenshot of the System Setting panel if need (although I don't see any way to attach it right now)

I'll have a look at the mozregression tool. Perhaps using a specific FF profile to avoid messing with mine.

May be I could also temporarily switch to another desktop environment (I have many installed, even if I only use KDE) and first, look for the "Focus follow mouse" feature, and also check the behavior of FF in these D.E.

Also note that this morning, FF is now at version 111.0.1, that I had to reboot (these day, I'm using the sleep most of the time), and after reboot, the resize handle are missing again. Same workaround : double click to put the FF window in (real ?) full screen, drag the FF window, and then, the resize handles are back again.

Comment 7

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

(In reply to [e-mail] from comment #6)

I'll have a look at the mozregression tool. Perhaps using a specific FF profile to avoid messing with mine.

mozregression uses dedicated profile and downloads test builds directly from Mozilla. It doesn't touch or break your recent setup.

Comment 8

[[:ChBe][e-mail]]

OK, nice.

Please note that I just made a simple test : I closed FF, rebooted, and I used the default profile (almost never used) and then switched back to my main profile (decades old bookmarks, a truck load of windows and tabs ...).
Remarks :

• default profile : no resize handle problem, but more important, the FF window is decorated by the KDE/Plasme window manager (kwin I think). It has all the common buttons (close, maximize, minimize, keep on top, etc).
• main profile : the window is fully decorated by FF. None of the common buttons are there. There are only the close, maximize and minimize buttons, specific to FF (different appearance and behavior, for instance, a wheel click on the maximize button does not maximize the window vertically, something any KDE window does).

I'll check my setting. Do you know if there's a switch that would allow to chose between the native window manager decoration and the FF one ? May be in the themes choice ?

Comment 9

[[:ChBe][e-mail]]

So far, no luck.
Nothing in the theme settings seems to have any influence on the window decoration. The current theme is "System theme — auto".
And none of my current add-ons too.

What could explain the different behaviors between the default profile and my current one ?

Comment 10

[[:ChBe][e-mail]]

A new serious lead I think. I just saw, above the mozregression tool section at this link https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool that there are environment variables that have a positive effect on my problem :

MOZ_GTK_TITLEBAR_DECORATION=client firefox

and

MOZ_GTK_TITLEBAR_DECORATION=system firefox

Using "system", everything is back to "normal", using the KDE decorations.
Using "client", FF uses its own window decorations. And in that case, these specific decorations don't cooperate nicely with the KDE/Plasma desktop environment.

Comment 11

[[:ChBe][e-mail]]

In addition, after a reboot, resize handle are fully functional when using the "system" decorations (which may appear as a tautology ...).
Do you think it's still useful to check with the mozregression tool ? The specific profile it uses may chose between "system" and "client" and stick to that choice, missing the point, don't you think ?

Comment 12

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

It may be a regression from Bug 1812289 then. Emilio, any idea here?

Comment 13

[Emilio Cobos Álvarez [:emilio]]

So you can disable the decorations from "customize mode": Right click -> Customize toolbar -> Check the "titlebar" checkbox. Does that fix the issue?

I'm not surprised move to front behavior is broken with CSD. Resizers work here with and without CSD tho (on Plasma 5.27).

Comment 14

[Emilio Cobos Álvarez [:emilio]]

Do other applications like gedit work the same btw?

Comment 15

[[:ChBe][e-mail]]

(In reply to [e-mail] from comment #11)

Additional detail : in the "system" mode, the other bug also disappear. I mean, it is now possible to bring a FF window to the first plane (remember the "Focus follow mouse" mode) by clicking on the title bar. But that's for the same reason than for the resize handle I guess : the title bar is also "property" of the window manager, not FF itself anymore.

Comment 16

[[:ChBe][e-mail]]

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

So you can disable the decorations from "customize mode": Right click -> Customize toolbar -> Check the "titlebar" checkbox. Does that fix the issue?

Yes, it does

I'm not surprised move to front behavior is broken with CSD. Resizers work here with and without CSD tho (on Plasma 5.27).

Maybe I missed the definition somewhere; what is CSD ? (no need to reply to this question specifically, it can wait)

Comment 17

[Emilio Cobos Álvarez [:emilio]]

CSD = client side decorations

Comment 18

[[:ChBe][e-mail]]

Thanks for the CSD explanation.

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

Do other applications like gedit work the same btw?

I just tried gedit before and after a reboot :

• appearance : it looks identical to FF, same reduced title bar, same dark gray color for the title bar and the resize handles
• behavior : I could not reproduce the resize handles bug with gedit after the reboot. Also, it does not behave like FF and accept to be brought to the first plane when clicking on the title bar

I also setup FF back to its original settings ("titlebar" checkbox unchecked) and rebooted : back to square one, resize handles not working, and no way to bring the window to the first plane.

Comment 19

[[:ChBe][e-mail]]

Additional tests : Gnome on Xorg, and MATE.
I could not find any "Focus follow mouse" in Gnome.
I found something close in MATE, but not exactly the same : a window gets the focus when the mouse cursor hovers it. But as soon as you click, the window goes to the first plane. That's not the case in KDE/Plasma.
Very quick test, but not resize handle or title bar bug seen in these two other desktop environments.

Packages versions :

• gedit : 3.38.1-1
• gnome : 3.38
• MATE : 1.24

Comment 20

[[:ChBe][e-mail]]

Few new hints, just in case they could help :

1. I talked about this with friends, heavy Linux users too. I can't describe precisely the condition of their respective tests. At least, they configured the behavior to "Focus follow mouse". One was using the standard, default behavior, the other one was using almost the same : "Focus follows mouse (mouse precedence)". Only the first one observed the same behavior/problem than me after switching to "Focus follow mouse".

2. They talked about something I did not know : GTK_USE_PORTAL=1. Both of my friends are using this.
   I did not had the time to test all the cases. But so far, I can't tell if this environment variable has any effect.
   I did test with gedit :

   • GTK_USE_PORTAL=1 has no influence on the problem I observed
   • here are two cases where gedit shows, and doesn't show, the bug :
     • no bug when gedit is a "normal" window; I mean, a window less than the size of the screen, both horizontally and vertically. I start gedit : no problem. I quit, then restart gedit : no problem
     • bug when gedit is "almost maximized". From the previous case, I dragged the top of the window to the top of the screen, and the bottom of the window to the bottom of the screen. I think I could say that the window manager (or something else ?) snapped the border of the window to the border of the screen when getting close enough (I mean that there may be something going on between the gedit's window, the window manager, KDE/Plasma desktop, I don't know ...). Then I quit and relaunch gedit. At this point, I don't have the ability to resize gedit's window. To regain control, I have to fully maximize the window by double clicking the title bar, then drag the entire window. It reduces its size, and give back the resize handles.

I hope this helps. Thank you for yours.