[Ubuntu] Firefox UI becomes corrupted when restarting the browser on a specific hardware configuration
Categories
(Core :: Graphics, defect, P3)
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.
Updated•6 years ago
|
Comment 1•6 years ago
|
||
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
Updated•6 years ago
|
Updated•6 years ago
|
Comment 2•6 years ago
|
||
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.
Comment 3•6 years ago
|
||
(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.
Comment 4•6 years ago
|
||
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.
Comment 5•6 years ago
|
||
:vlucaci, does the problem happen with latest nightly?
Comment 6•6 years ago
|
||
From the symptom, I wonder if gfk's nsWindow::mBounds is not updated correctly.
Comment 7•6 years ago
|
||
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
Reporter | ||
Comment 8•6 years ago
|
||
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.
Comment 9•5 years ago
|
||
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.
Comment 10•5 years ago
•
|
||
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.
Comment 11•3 years ago
|
||
I’ve encountered the same issue with the session restore option on Ubuntu 20.04x64.
Steps to reproduce
- Launch Firefox and maximize it.
- Access some websites.
- Open another window and access any page and mnimize it.
- Quit Firefox from the maximized window.
- Reopen Firefox with the same profile.
- 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.
Comment 12•3 years ago
|
||
Updated•3 years ago
|
Updated•2 years ago
|
Comment 13•1 year ago
|
||
Is this still a problem when using the latest version?
Reporter | ||
Comment 14•1 year ago
|
||
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.
Updated•1 year ago
|
Description
•