Open Bug 1829004 Opened 2 years ago Updated 2 years ago

Gtk/DecorationLayout is not respected

Categories

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

defect

Tracking

()

REOPENED
Tracking Status
thunderbird_esr102 --- unaffected

People

(Reporter: bodqhrohro, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [Supernova3p])

Attachments

(1 file)

Attached image tbcsd.png

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

Steps to reproduce:

@bq:00:06:26:/tmp/dl$ cat ~/.xsettingsd |grep DecorationLayout
Gtk/DecorationLayout "menu,close:minimize,maximize"
@bq:00:29:40:/tmp/dl$ cat ~/.xsettingsd |grep /ThemeName
Net/ThemeName "Gradient-blue-324.2"
@bq:00:29:44:/tmp/dl$ cat ~/.xsettingsd |grep DPI
Xft/DPI 141767

Actual results:

In ≤112, buttons were in the close,minimize,maximize: order.

After upgrading to 113, they're in the minimize,maximize,close: order, and the gap between the 1st and 2nd button is bigger than between 2nd and 3rd. Both orders don't respect the setting.

Expected results:

Display the buttons according to the DecorationLayout setting. I attached an example of a CSD GTK+3 app (Dconf) at side which respects the setting.

There also is a problem with the size of the buttons. In native GTK+3 apps, they looked bigger on another laptop with a 100 DPI screen, so seems like GTK+3 does not respect the DPI there. Thunderbird, OTOH, seems to scale the images up to match the physical size with 141 DPI. I'm not sure what behaviour is more correct, actually, but even if GTK+3 behaviour is incorrect, Thunderbird should probably match it anyway for compatibility reasons.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Duplicate of bug: 1828530
Keywords: regression
Resolution: --- → DUPLICATE

Bug 1828530 is about a much more narrow case, and it got a quick&dirty fix which only reverses the order of buttons and does neither take the layout setting into account nor add support for placing the buttons at both sides of the window in arbitrary order. Buttons at both sides of the window are a default at least on Elementary OS, so it's not some obscure use case.

Still relevant in 113.0b5: the order is different and still totally wrong: http://0x0.st/HPf2.png

Status: RESOLVED → REOPENED
No longer duplicate of bug: 1828530
Ever confirmed: true
Resolution: DUPLICATE → ---
Whiteboard: [Supernova3p]

bodqhrohro , does Firefox respect the order? I think not and then this should be a toolkit bug.

I have server-side decorations in Firefox, does it support client-side decorations too? How do I enable them?

Try in about:config set browser.tabs.inTitlebar to 2.

Ah, I have #TabsToolbar hidden and thus didn't see it. Yes, it's the same on a clean profile: http://0x0.st/HPWn.png

Component: OS Integration → Widget: Gtk
Product: Thunderbird → Core
Version: Thunderbird 113 → unspecified
Blocks: gtktitlebar
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: