Launchpad has imported 3 comments from the remote bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=1677259.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2020-11-14T02:28:59+00:00 Lrebrown wrote:

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+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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1940707/comments/0

------------------------------------------------------------------------
On 2020-11-14T03:17:44+00:00 Release-mgmt-account-bot wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1940707/comments/1

------------------------------------------------------------------------
On 2020-11-30T12:15:10+00:00 Release-mgmt-account-bot wrote:

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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1940707/comments/2


** Changed in: firefox
       Status: Unknown => New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1940707

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

Status in Mozilla Firefox:
  New
Status in firefox package in Ubuntu:
  Confirmed

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/1940707/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to