59 bytes, text/x-review-board-request
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20170925150345 Steps to reproduce: In bug 1404337 there is a patch to hide the drag space on the left and right of the tab bar when the window is maximized. I'm opening this bug mostly for discussion, as I'm not too invested either way, but I've noticed that this isn't consistent with Edge, which seems to be the only other browser that currently ships with a similar design. When maximized, Edge leaves the drag space to the right of the tabs in place, and it can be double-clicked to restore the window (some people's muscle memory might be used to this, as opposed to hitting the restore button perhaps? maybe this is why microsoft left it there?). Personally I think it makes sense to hide the drag space on the left, but maybe not the one on the right. One of the things I found interesting about Edge when it first shipped, is how bold Microsoft was in eliminating the titlebar completely, unlike Chrome which leaves a little bit at the top, but then I realized that since the browser initially starts with one tab, and it's intuitive to just use the empty space to drag the window, and then as the space shrinks when you open more tabs, the browser intuitively teaches you to just keep using whatever space "remains" at the right, which I thought was actually brilliant design in a sense. By the way, in Linux, it's common for most window managers to allow you to click drag space in a window, and "drag" a maximized window, which instantly restores it and lets you move the restored window around, instead of first needing to restore, and then grabbing and moving as a second step. So even if it's decided that hiding it on Windows makes sense, it may still make sense to leave some drag space on the right of the tab bar on Linux. Another Linux issue, and perhaps a little off-topic, but bug 1283299 seems to be nearing completion, and at least on Gnome it's the convention to not have minimize or maximize/restore buttons by default (this is configurable); whether Firefox wants to match this is a different subject altogether, but if this is desirable, then the double-click of drag space becomes the only way to max/restore the window. Anyways, I think that's everything, discuss.
Ok, as https://bugzilla.mozilla.org/show_bug.cgi?id=1404337#c5 is rightfully stating this was just sloppiness on my part because I really need to go on a weekend. This is going to be fun to uplift...
No problem :) take your time and enjoy the weekend :) At the end of the day there is still an option to back-out Bug 1404337 and Bug 1397265 I guess, and try to uplift only this one.
Comment on attachment 8914300 [details] Bug 1404497 - Don't hide the post-tabs titlebar placeholder in maximized windows. https://reviewboard.mozilla.org/r/185590/#review190940
Attachment #8914300 - Flags: review?(dao+bmo) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/c3c3422dd17c Don't hide the post-tabs titlebar placeholder in maximized windows. r=dao
Comment on attachment 8914300 [details] Bug 1404497 - Don't hide the post-tabs titlebar placeholder in maximized windows. Approval Request Comment [Feature/Bug causing the regression]: Bug 1404337 [User impact if declined]: Inconsistent window drag space [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: Yes [Needs manual test from QE? If yes, steps to reproduce]: Not really. [List of other uplifts needed for the feature/fix]: Bug 1397265 and bug 1404337. [Is the change risky?]: No [Why is the change risky/not risky?]: The change is quite simple and people were extensively testing this on Nightly already. It's unlikely that we find additional problems. [String changes made/needed]: None
Attachment #8914300 - Flags: approval-mozilla-beta?
Comment on attachment 8914300 [details] Bug 1404497 - Don't hide the post-tabs titlebar placeholder in maximized windows. Another recent regression, Beta57+
Attachment #8914300 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
I verified this issue using Nightly 58.0a1 and Firefox 57.b9 with Build ID 20171016185129 on Windows 10 x64, Mac OS X 10.12, Windows 7 x64 I will mark this as verified fixed.
You need to log in before you can comment on or make changes to this bug.