1677259 - Restored session with maximised window uses wrong window dimensions

Status: RESOLVED DUPLICATE of bug 1630251

(Core :: Widget: Gtk, defect)

Description

[Lyndon]

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

Steps to reproduce:

For the past few major firefox versions (at least) I've been experiencing an issue on Linux whereby when opening firefox (which I always use maximised and with session-restore enabled) the window frame ends up maximised, but with the window content (including titlebar elements) incorrectly drawn and positioned using the un-maximised window dimensions.

To be clear, this is not just a content drawing issue, it's a positioning issue also - the actual window min/max/close buttons, for instance, are positioned according to the un-maximised window width from the left side of the screen.

This typically if not exclusively seems to happen when I alt+tab away to a different app during loading of firefox, or at least it is more likely to re-occur if I do that.

I'm using Debian Sid, with Gnome & Wayland. I have a HiDPI screen.

This seems related to #1388670, possibly a duplicate, though that seems to focus on a situation with a specific setting that does not apply to me if you go by its title. This also describes the situation with webrenderer enabled (which is worse), for what that's worth.

This is also possibly related to #1454156, which itself plays a part in poor startup behaviour and the fix for which may surely play some part in fixing the problem(s).

Actual results:

The startup experience follows this pattern: Initially the window starts out maximised with a single new empty tab. It takes several seconds to process the session data (I have a lot of open tabs, in the region of 2000+). As soon as it is done with that processing, the behaviour of #1454156 is seen, i.e. the window is suddenly replaced/resized giving an un-maximised window with the restored tabs; a split second later it is then restored to maximised again.

After this silly max->unmax->max cycle the window content then sometimes is left stuck incorrectly at the un-maximised window dimensions. The details of this differ somewhat with webrenderer enabled, which I'll describe shortly in case it is of interest in fixing webrenderer bugs, especially since things are significantly worse under webrenderer. Without webrenderer the window content is simply drawn and elements positioned, using unmaximised-window dimensions, from the top left of the maximised window frame, with the remainder of the window area shown black.

A quick workaround when this happens is to either double-click the titlebar or otherwise click the maximise button, such that the window becomes un-maximised; You can then re-maximise it, following which it will then be resized correctly.

The problem typically or exclusively seems to occur when I alt+tab away to a different application during the firefox startup, though does not seem to reliably do so every single time. So for instance, if I turn on my computer, login, open my email application, open firefox, and just sit and wait for firefox to fully load with my restored session, it usually (or always?) does things correctly. However, if while firefox is sat processing the session data during its startup (remember, I have lots of tabs and so this takes multiple seconds for me), I alt+tab away to my email program to start reading email in the mean time, some seconds later once firefox has processed the session data, it then tries to steal focus, forcing itself on top of the mail application window (a bug in itself - is there an existing report?), requiring three alt+tabs (iirc) to switch back to the email I was reading. Or rather perhaps it's not stealing focus, but just incorrectly has its window drawn in the foreground instead of the background, not having bothered to recheck that it had focus? In this case it will sometimes encounter the window content dimension issue.

Note, pressing alt to toggle the old window menu just updates the wrongly-drawn window content accordingly, it does not correct the dimensions used.

With gfx.webrenderer.all enabled, behaviour is similar but worse. The key difference is, after taking several seconds to process the session data, what results from it then re-maximising the window:

• again the un-maximised dimensions are incorrectly used to draw and position the window content within the maximised window frame.
• this displayed content appears in the bottom left rather than top left.
• the area to the right, with firefox having forced itself to the foreground over my maximised email client, shows a portion of said email client. (The firefox window is definitely maximised covering the entire screen width since if you click on the emails nothing happens, you have to triple alt-tab back to the email client to interact with them).
• the portion above the proper window content (remember, with webrenderer it's placed in the bottom left), of the same width as the content, is a little tricky to describe and is not always the same. In one case it showed a copy of the window content but with no favicons or tab content, as though the window content started to be drawn there before being moved down. In other cases this area has contained a load of rapidly flickering content that looked as though a copy of the window content was animatedly moving up/down within that rectangle, and this was accompanied with my computer's fans kicking in, demonstrating a tax on processing resources.
• The content of the last two areas just mentioned are set to fully transparent after alt+tabbing away and back again.
• While the content is drawn in the bottom left portion of the window frame, the actual elements are located in the top left portion, just as without webrenderer. This results in a disconnect between the drawn GUI controls and where the actual controls are placed. Thus if you try to click on tabs or double-click the titlebar, or click the min/max/close buttons, nothing happens because the actual elements are not located where you see them. If you hover your cursor over the area at the top of the window frame where they are actually located, you'll see the corresponding highlight effects appearing in the drawn content further below; tooltips will appear next to the actual controls as you'd expect. This disconnect of course impacts the ability to use the described unmax->max workaround to get the window reconstructed correctly since you have to firstly understand the disconnect, then move your cursor around roughly the location the maximise button actually exists to find and use it.

Expected results:

Firefox should not be encountering this issue determining the correct dimensions to use for window content drawing and placement. Nor should it be giving the poor UX of the behaviour described by #1454156 that is intrinsically linked to this perhaps. I'd expect Firefox to directly update the initial maximised window it correctly created with the tabs of the previous session, rather than this messy max->unmax->max cycle which creates the opportunity for this sizing problem to occur.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mikedeboer, could you have a look please?

For more information, please visit auto_nag documentation.