Open Bug 1257792 Opened 8 years ago Updated 2 years ago

figure out how to adapt tabs-in-titlebar when the titlebar controls are taller than the tabs, hence pushing them down from top-of-screen when the window is maximized

Categories

(Firefox :: Tabbed Browser, defect)

defect

Tracking

()

People

(Reporter: jfkthame, Unassigned)

References

Details

Windows 8.1 (and 10, I believe) with mixed screen resolutions does *not* scale the non-client parts of the window (borders & titlebar, minimize/maximize/close buttons) for the current screen, but always renders them according to the resolution scale factor of the primary display.

This means that the dimensions of these elements, in CSS px terms, will change when a window moves between screens with different resolutions. They'll have the "correct" dimensions (and look in proportion to the window contents) only at the primary display's resolution.

In particular, if the primary display is hi-dpi and a secondary monitor is lo-dpi, the window frame & controls will look correspondingly fatter on the lo-dpi monitor. With primary display scaling at 200% and secondary at 100%, for example, the window-control buttons become significantly taller than the browser tabs.

When the window is maximized, with titlebar and menubar hidden, on the secondary lo-dpi display, therefore, the tabs can't be "pulled" up all the way to the top of the screen, because then the window controls would overlap into the following toolbar, as seen in attachment 8731260 [details] in bug 1256731, and fixed (by not pulling the tabs up so far) in patch 3 of that bug.

However, this means the tabs are no longer at top-of-screen, and we've lost the Fitts' Law benefit of the maximized window.

Presumably, with a sufficiently great DPI discrepancy, even the menu bar could also be affected in this way. (At 2:1, the combined height of tabs + menubar on the lo-dpi screen is sufficient that the menus remain at the top. But even greater resolution differences are possible, which would make the window controls correspondingly larger and make this problem more extreme.)

So as a followup to bug 1256731, which at least fixed the visual overlap, we should consider whether some further redesign or different implementation would be better. Taller tabs? Extend the hit area of the tabs upwards (even if they're not made visibly taller), so that it's possible to click above a tab title and still select it? Some other idea?

(Alternatively, if we can find a way to overcome Windows' lack of non-client scaling, so that we can draw the window frame and its controls at the "expected" size on secondary displays, this problem would go away.)
AIUI bug 1256731 will track 47 if all goes to plan. It would be good if we didn't regress this for 47, but regressing Fitts would be better than the overlapping thing, I guess.

Dolske, can we track this for the qx project?
Blocks: 1256731
Flags: needinfo?(dolske)
(In reply to :Gijs Kruitbosch from comment #1)
> AIUI bug 1256731 will track 47 if all goes to plan.

That's the current goal, yes.

> It would be good if we
> didn't regress this for 47, but regressing Fitts would be better than the
> overlapping thing, I guess.

I think so, especially considering that this will only be an issue for the (presumably small) minority of users who have the particular combination of screens with sufficiently-differing DPIs, choice of primary monitor, etc.
This seems to be working now (at least with a current Nightly and the newest Win10 Insider build I'm using). I've got an external display plugged in, one display is 100% and the other 200%.

When the Nightly window is entirely on one display or the other, it's displayed as I'd expect. I'm not seeing anything abnormal about the window controls or tab position. When maximizing the window the top of the tabs is always at the top of the window.

I really only see two odd issues, and Edge behaves the same way:

* When a window spans displays, the minority part of the window (on the "wrong" display) isn't scaled at all, so it's either grossly large or small.

* When dragging a window between displays, Windows sometimes seems to get confused about the window dimensions. So after dragging a window to another display and then back, it sometimes ends up filling the screen even though I didn't resize it.
Flags: needinfo?(dolske)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.