Open Bug 1505027 Opened 6 years ago Updated 1 year ago

[Ubuntu] Firefox UI becomes corrupted when restarting the browser on a specific hardware configuration

Categories

(Core :: Graphics, defect, P3)

Desktop
Linux
defect

Tracking

()

Tracking Status
firefox-esr60 --- affected
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- fix-optional
firefox66 --- fix-optional
firefox85 --- wontfix
firefox86 --- wontfix
firefox87 --- fix-optional

People

(Reporter: vlucaci, Unassigned)

Details

(Keywords: regression)

Attachments

(2 files)

[Affected versions]:

- 64.0b7
- 65.0a1 (2018-11-06)
- 63.0

[Affected platforms]:

- Ubuntu 16.04 x64
- Ubuntu 16.04 x86
- Ubuntu 18.04 x64

[Steps to reproduce]:

1. Launch FF with a fresh profile.
2. Set the window to be either full screen or windowed.
3. Restart the browser either via Shift+F2 or via CTRL+Shift+J/CTRL+ALT+R.

[Expected result]:

- The browser is restarted without any corrupted UI elements.

[Actual result]:

- Upon restarting the browser, the right side and footer of the window is corrupted.

[Regression range]:

- https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=25aad10380b10b6efa50c2b4d97245f078d870a0&tochange=a31334a65a1c75638efae4452ecd271450df2ad0

-Attachments of the issue:
(Video of the issue, Images and about:support information)
https://drive.google.com/drive/folders/1hODl0F2H5zItOuvemY8GaqOanrYHPERP?usp=sharing

[Additional notes]:

- This issue does not reproduce on any other work station except on the following hardware configuration:

Processor: Intel Core i3-5005U CPU @ 2.00GHz x 4
Memory: 4 GB RAM
Graphics: Intel @ HD Graphics 5500 (Broadwell GT2)

-This issue occurs even while in full screen or in windowed mode. Issue can also occur if restarting the browser as a user would. Above methods were used as an example.
This is happening with the basic compositor, so it is theoretically platform agnostic. OMTP wasn't enabled on Linux by default until 2018 so I think we can rule out that.

Nothing jumps out at me from the regression range as obviously related, so it is probably a second order effect from another change. Maybe one of these?
	e0c53e24ab2a	sotaro — Bug 1391262 - Create TabChild::CreateRemoteLayerManager() r=dvander
	38330dd0d9e5	sotaro — Bug 1391262 - Do not use remote LayerManager when its initialization fails r=dvander 
	d6fdc1d3b070	Timothy Nikkel — Bug 1405397. Part 2. ScrollFrameHelper::BuildDisplayList should only have one way to determine if we are using a displayport/building a async scrollable layer. r=mstange
	bda0ae08740f	Timothy Nikkel — Bug 1405397. Part 1. Only add scrollbars in the "ignore scroll frame" case if we are painting to the window. r=mstange
Priority: -- → P3
Flags: needinfo?(tnikkel)
Flags: needinfo?(sotaro.ikeda.g)
If my layout change had an effect (even invisible in the vast majority of cases) I'd expect to have heard about some sort of fallout from it by now.
Flags: needinfo?(tnikkel)
(In reply to Timothy Nikkel (:tnikkel) from comment #2)
> If my layout change had an effect (even invisible in the vast majority of
> cases) I'd expect to have heard about some sort of fallout from it by now.

An effect on the default UI that is, not some weird random webpage with special edge cases.
From symptom, it seems that Widget seems not have correct size and pos info. Bug 1391262 does not change how widget size and pos are calculated. Then Bug 1391262 seems not related to the bug.

I tried to reproduce the problem on Ubuntu 18.04 x64 with Firefox 63. I could reproduce the problem once, but I failed to reproduce the problem since then.
Flags: needinfo?(sotaro.ikeda.g)
:vlucaci, does the problem happen with latest nightly?
Flags: needinfo?(vlad.lucaci)
From the symptom, I wonder if gfk's nsWindow::mBounds is not updated correctly.
If nsWindow::OnSizeAllocate() worked as expected, it invalidate the new part of the window.
  https://dxr.mozilla.org/mozilla-central/source/widget/gtk/nsWindow.cpp#2442
Hello, 

To answer the question from Comment 5:

Yes, this issue occurs with the exact same repro steps on the latest Nightly 65.0a1(2018-11-22) and the latest Beta as well 64.0b11.
Flags: needinfo?(vlad.lucaci)
Since this is triaged and has a priority set, marking this fix-optional to remove it from regression triage. 
Happy to still take a patch in nightly.

The issue is still reproducible when updating from 60.5.1esr to 60.6.0esr (20190313191546) in fullscreen on Ubuntu 18.04 x64 on the same system configuration described in the additional notes of comment 0.

I’ve encountered the same issue with the session restore option on Ubuntu 20.04x64.

Steps to reproduce

  1. Launch Firefox and maximize it.
  2. Access some websites.
  3. Open another window and access any page and mnimize it.
  4. Quit Firefox from the maximized window.
  5. Reopen Firefox with the same profile.
  6. Go to hamburger menu and click on “Restore Previous Session”

Expected result

  • Previous session is successfully restored and both windows are displayed correctly.

Actual result

  • Maximized window is displayed faulty.

I'll attach a screen record of the issue.

Severity: normal → S3

Is this still a problem when using the latest version?

Flags: needinfo?(vlad.lucaci)
Flags: needinfo?(maria.berlinger)

Hello

I have tried to reproduce this issue on 110.0a1(buildID=20230111215657), 109.0(buildID=20230109161414) with Ubuntu 16, 18 , 20 and 22 and was unable to reproduce this issue anymore.

It is worth mentioning that I no longer have access to the configuration on which this issue was reported (from Description) so the issue might still be present there.

Flags: needinfo?(vlad.lucaci)
Flags: needinfo?(mberlinger)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: