Mozilla Firefox

[upstream] Maximized window becomes a mess at next startup after manually choosing to restore previous session

Bug #1940707 reported by Akbarkhon Variskhanov on 2021-08-20

This bug affects 2 people

Affects		Status	Importance	Assigned to	Milestone
	Mozilla Firefox	Invalid	Unknown	mozilla-bugs #1677259
	firefox (Ubuntu)	Confirmed	Undecided	Unassigned

Bug Description

Checked on both current and new user. This behavior is observed only if "Restore previous session" is not enabled to occur automatically at startup.

1) Ubuntu 20.04.2 LTS
2) 91.0+build2-0ubuntu0.20.04.1
3) "Restore previous session" should not change window settings and appearance
4) "Restore previous session" drastically changes window settings and appearance in a very unpleasant way

Steps to reproduce:
1) Don't have "Restore previous session" enabled in Settings > General > Startup
2) Browse some sites
3) Close the window and confirm your desire to close it
4) Reopen Firefox
5) Go to History and select "Restore previous session"
6) The window will break apart as a result

Screenshot below.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: firefox 91.0+build2-0ubuntu0.20.04.1
ProcVersionSignature: Ubuntu 5.11.0-27.29~20.04.1-generic 5.11.22
Uname: Linux 5.11.0-27-generic x86_64
AddonCompatCheckDisabled: False
ApportVersion: 2.20.11-0ubuntu27.18
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: kbar 1005 F.... pulseaudio
/dev/snd/controlC1: kbar 1005 F.... pulseaudio
BuildID: 20210804193234
CasperMD5CheckResult: skip
Channel: Unavailable
CurrentDesktop: XFCE
Date: Fri Aug 20 23:27:25 2021
DefaultProfileExtensions: extensions.sqlite corrupt or missing
DefaultProfileIncompatibleExtensions: Unavailable (corrupt or non-existant compatibility.ini or extensions.sqlite)
DefaultProfileLocales: extensions.sqlite corrupt or missing
DefaultProfilePrefErrors: Unexpected character ',' before close parenthesis @ /usr/lib/firefox/omni.ja:greprefs.js:352
DefaultProfileThemes: extensions.sqlite corrupt or missing
ForcedLayersAccel: False
InstallationDate: Installed on 2021-05-17 (95 days ago)
InstallationMedia: Xubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1)
IpRoute:
default via 192.168.1.1 dev wlo1 proto dhcp metric 600
169.254.0.0/16 dev wlo1 scope link metric 1000
192.168.1.0/24 dev wlo1 proto kernel scope link src 192.168.1.102 metric 600
Profile0Extensions: extensions.sqlite corrupt or missing
Profile0IncompatibleExtensions: Unavailable (corrupt or non-existant compatibility.ini or extensions.sqlite)
Profile0Locales: extensions.sqlite corrupt or missing
Profile0PrefErrors: Unexpected character ',' before close parenthesis @ /usr/lib/firefox/omni.ja:greprefs.js:352
Profile0PrefSources: prefs.js
Profile0Themes: extensions.sqlite corrupt or missing
Profiles:
Profile1 (Default) - LastVersion=None/None (Out of date)
Profile0 - LastVersion=91.0/20210804193234
RunningIncompatibleAddons: False
SourcePackage: firefox
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/18/2014
dmi.bios.release: 15.54
dmi.bios.vendor: Insyde
dmi.bios.version: F.36
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: 220D
dmi.board.vendor: Hewlett-Packard
dmi.board.version: 86.49
dmi.chassis.asset.tag: Chassis Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.chassis.version: Chassis Version
dmi.ec.firmware.release: 86.49
dmi.modalias: dmi:bvnInsyde:bvrF.36:bd12/18/2014:br15.54:efr86.49:svnHewlett-Packard:pnHP14NotebookPC:pvr0975120000405F00000610180:rvnHewlett-Packard:rn220D:rvr86.49:cvnHewlett-Packard:ct10:cvrChassisVersion:
dmi.product.family: 103C_5335KV G=N L=CON B=HP S=PAV
dmi.product.name: HP 14 Notebook PC
dmi.product.sku: L8N69PA#UUF
dmi.product.version: 0975120000405F00000610180
dmi.sys.vendor: Hewlett-Packard

See original description

Tags:

Revision history for this message

In Mozilla Bugzilla #1677259, Lrebrown (lrebrown) wrote on 2020-11-14:

Download full text (6.9 KiB)

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.

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

Steps to reproduce:

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 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 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+tab`s (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+tab`bing 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.

Revision history for this message

In Mozilla Bugzilla #1677259, Release-mgmt-account-bot (release-mgmt-account-bot) wrote on 2020-11-14:

[Bugbug](https://github.com/mozilla/bugbug/) thinks this bug should belong to this component, but please revert this change in case of error.

Revision history for this message

In Mozilla Bugzilla #1677259, Release-mgmt-account-bot (release-mgmt-account-bot) wrote on 2020-11-30:

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

For more information, please visit [auto_nag documentation](https://wiki.mozilla.org/Release_Management/autonag#workflow.2Fno_severity.py).

Revision history for this message

Akbarkhon Variskhanov (kbar) wrote on 2021-08-20:

firefox.png Edit (119.8 KiB, image/png)
AlsaInfo.txt Edit (42.3 KiB, text/plain; charset="utf-8")
CurrentDmesg.txt Edit (89.0 KiB, text/plain; charset="utf-8")
Dependencies.txt Edit (5.3 KiB, text/plain; charset="utf-8")
IpAddr.txt Edit (881 bytes, text/plain; charset="utf-8")
Lspci.txt Edit (11.0 KiB, text/plain; charset="utf-8")
PciNetwork.txt Edit (1.4 KiB, text/plain; charset="utf-8")
ProcCpuinfoMinimal.txt Edit (1.3 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (325 bytes, text/plain; charset="utf-8")
Profile0Prefs.txt Edit (1.1 KiB, text/plain; charset="utf-8")
PulseList.txt Edit (19.9 KiB, text/plain; charset="utf-8")

Akbarkhon Variskhanov (kbar) on 2021-08-21

description:	updated
summary:	- Maximized window becomes a mess at next start-up after manually choosing + Maximized window becomes a mess at next startup after manually choosing to restore previous session

Revision history for this message

Akbarkhon Variskhanov (kbar) wrote on 2021-08-21: Re: Maximized window becomes a mess at next startup after manually choosing to restore previous session

I assume that privacy.resistFingerprinting preference is somehow being enabled before sessionstore-backups are loaded which is why the window state appears unmaximized and distorted.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2021-10-17:

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in firefox (Ubuntu):
status:	New → Confirmed

Revision history for this message

Olivier Tilloy (osomon) wrote on 2021-10-19:

That sounds like an upstream bug, possibly https://bugzilla.mozilla.org/show_bug.cgi?id=1677259.

summary:	- Maximized window becomes a mess at next startup after manually choosing - to restore previous session + [upstream] Maximized window becomes a mess at next startup after + manually choosing to restore previous session
tags:	added: upstream

Bug Watch Updater (bug-watch-updater) on 2021-10-19

Changed in firefox:
status:	Unknown → New

Revision history for this message

In Mozilla Bugzilla #1677259, W-jan-k (w-jan-k) wrote on 2021-11-04:

*** This bug has been marked as a duplicate of bug 1630251 ***

Bug Watch Updater (bug-watch-updater) on 2021-11-06

Changed in firefox:
status:	New → Invalid

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

mozilla-bugs #1677259
[RESOLVED DUPLICATE] Edit

Bug watches keep track of this bug in other bug trackers.

Mozilla Firefox

[upstream] Maximized window becomes a mess at next startup after manually choosing to restore previous session

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches