User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0 Build ID: 20180321102906 Steps to reproduce: 1. Use latest KDE Plasma (5.12.3) 2. Check "Drag Space" checkbox (i.e. enable drag space) 3. Uncheck "Title Bar" checkbox (i.e. enable CSD) 3. Maximize window Actual results: Window controls(close, maximize, minimize) aren't centered vertically. Expected results: Window controls(close, maximize, minimize) should be centered vertically.

For reference, this is how Firefox looks with drag space being disabled.

This affects only maximized windows, right? In that case the drag space is not rendered (it's rendered at normal state only AFAIK).

Yes, I can reproduce that on gnome-shell/Adwaita theme too.

(In reply to Martin Stránský [:stransky] from comment #2) > In that case the drag space is not rendered (it's rendered at normal state only AFAIK). I'd like to point out that there is a little space above tabs when Firefox is maximized and the drag space is disabled. Yet, there is no space above tabs when the drag space is enabled (when Firefox is maximized). :D

Window buttons are vertically centered. Did you fix that?

Looks like we need to call some refresh when maximize/unmaximize here. When the icons are rendered incorrectly it's enough to toggle menu bar and the rendering is fixed (at least for me).

(In reply to Martin Stránský [:stransky] from comment #6) > Looks like we need to call some refresh when maximize/unmaximize here. When > the icons are rendered incorrectly it's enough to toggle menu bar and the > rendering is fixed (at least for me). OK, after playing with enabling/disabling drag space and maximizing/unmaximizing Firefox, I could reproduce the bug again. Toggling menu bar helped me too.

This is a variant of Bug 715867. sizemodechange/resize is fireed *before* actual window.sizemode attribute is changed. The sequence is: 1) Window size is changed 2) sizemodechange/resize is fired 3) TabsInTitlebar._layOutTitlebar() calculates new titlebar size but with old TabsToolbar.height value: let fullTabsHeight = rect($("TabsToolbar")).height; 4) sizemode is set to "normal", CSS rule applies: /* Add extra space to titlebar for dragging */ :root[sizemode="normal"][chromehidden~="menubar"] #TabsToolbar, :root[sizemode="normal"] #toolbar-menubar[autohide="true"][inactive] + #TabsToolbar { padding-top: var(--space-above-tabbar); } 5) TabsToolbar has extra padding which causes icons are not centered.

Sizemode attribute is updated by nsXULWindow::SavePersistentAttributes() which is fired by timer. I wonder how that does work on other systems...

(nothing to do with event handling.)

This is probably going to regress something. :) You should fire off a try run on multiple platforms for this just to check.

Comment on attachment 8967302 [details] Bug 1447775 - Change persist mode immediately after sizemodechange change, https://reviewboard.mozilla.org/r/235984/#review242340

You're right, there's a regression on MacOS: https://treeherder.mozilla.org/logviewer.html#?job_id=173232063&repo=try&lineNumber=20399 03:35:57 INFO - GECKO(2280) | [2280, Main Thread] ###!!! ASSERTION: mBounds out of sync!: 'mWindow && mBounds == r', file /builds/worker/workspace/build/src/widget/cocoa/nsCocoaWindow.mm, line 1717 03:35:57 INFO - GECKO(2280) | #01: nsBaseWidget::GetRestoredBounds(mozilla::gfx::IntRectTyped<mozilla::LayoutDevicePixel>&) [widget/nsBaseWidget.cpp:1661] 03:35:57 INFO - 03:35:57 INFO - GECKO(2280) | #02: nsXULWindow::SavePersistentAttributes() [xpfe/appshell/nsXULWindow.cpp:1628]

Dao, is this one also covered by bug 1356920? Thanks.

(In reply to Martin Stránský [:stransky] from comment #17) > Dao, is this one also covered by bug 1356920? Thanks. Yeah, I guess it would fix this.

I believe this is fixed.