Closed Bug 1904190 Opened 3 months ago Closed 2 months ago

Surface Pro X : Since the 127 update, parts of the display is filled with white squares, or with the wrong colours.

Categories

(Core :: Graphics: WebRender, defect)

Firefox 127
defect

Tracking

()

RESOLVED FIXED
129 Branch
Tracking Status
firefox-esr115 --- unaffected
firefox-esr128 --- fixed
firefox127 --- wontfix
firefox128 --- fixed
firefox129 --- fixed

People

(Reporter: dark.angel, Assigned: nical)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0

Steps to reproduce:

Updated to 127 version.
Also tried with nigthly 128.

Actual results:

Parts of the dispay are filled with white square.
Some other reports on Reddit : https://www.reddit.com/r/firefox/comments/1df9szu/so_i_guess_the_latest_version_of_firefox_was/

A way to fix it is to disable hardware acceleration.

gfx.webrender.software does help, but I suppose it's the same as disabling hardware acceleration.
Video rendering become sluggish (especially during page rendering).

The Bugbug bot thinks this bug should belong to the 'Core::Graphics' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Graphics
Product: Firefox → Core

Can you type about:support in the address bar of your browser, and copy its contents and attach them on this bug?

Flags: needinfo?(dark.angel)
Flags: needinfo?(dark.angel)

(In reply to Mayank Bansal from comment #3)

Can you type about:support in the address bar of your browser, and copy its contents and attach them on this bug?

Yes, of course. File Added.

Was Firefox working as expected in V126 (or earlier)?

If yes, could you please use https://mozilla.github.io/mozregression/ (use the Windows gui version), and perform a bisection to find which change caused this issue for you?
The mozregression tool is quite user friendly, manages all the downloads/installation/uninstallation/cleanup automatically. The "good" version would be V126 (or whichever version was working well for you) and the "bad" version would be V127.

Flags: needinfo?(dark.angel)
See Also: → 1903048

It seems we might have a problem with Adreno on Windows, bug 1903048 seems to have collected some similar bugs.

I didn't know about mozregression. Sounds interesting.
Unfortunately, I ran into antother issue with it, as it crash while starting:

platform: Windows-10-10.0.22631-SP0
python: 3.10.11 FROZEN (64bit)
mozregression: 6.2.2
message: UnicodeEncodeError: 'ascii' codec can't encode character '\xe7' in position 23: ordinal not in range(128)
traceback: File "mozregression-gui.py", line 6, in <module>
File "mozregui\main.py", line 35, in main
File "mozregui\global_prefs.py", line 66, in set_default_prefs
File "mozregui\global_prefs.py", line 57, in save_prefs
File "configobj_init_.py", line 2117, in write

Flags: needinfo?(dark.angel)

(In reply to Timothy Nikkel (:tnikkel) from comment #7)

It seems we might have a problem with Adreno on Windows, bug 1903048 seems to have collected some similar bugs.

True.
This looks quite similair to this issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=1852440

But I tried the force-corner, and it wouldn't help.

If you have the time and patience, may i suggest re-installing mozregression with admin privilege, and then running it with admin privileges. Sometimes doing that makes it work.

I wonder if the mozregression folks, with this info, would be able to fix the problem in future versions?

(In reply to Mayank Bansal from comment #10)

If you have the time and patience, may i suggest re-installing mozregression with admin privilege, and then running it with admin privileges. Sometimes doing that makes it work.

Nope. Still the same.
I'll try later to install python and launch in command line.

(In reply to Timothy Nikkel (:tnikkel) from comment #11)

I wonder if the mozregression folks, with this info, would be able to fix the problem in future versions?

mozregression, Python wouldn't build either. I found out my culprit was about my username (Full Name with special characters).
I tested with another Windows profile.

Attached file mozregression.log

I attached the full mozregression log.
I love this tool!

Thanks! The last lines of the log says this :

Bug 1888628 - Extract the texture sampling logic out of ps_quad.glsl. r=gw

This simplifies the common infrastructure, removes two varyings from the common set and will allow other patterns to handle sampling differently if they need it (for example an upcoming repeating pattern).

In addition:

  • the color parameter is always passed to the fragment shader (it used to be only when no uv_rect was passed).
  • v_flags was reorganized a bit so that w is used by the common infrastructure and xyz are available for patterns to use.

Differential Revision: https://phabricator.services.mozilla.com/D206098

So bug 1888628 is the regressor.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Regressed by: 1888628

This bug may be a duplicate of bug 1897444

Set release status flags based on info from the regressing bug 1888628

:nical, since you are the author of the regressor, bug 1888628, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Flags: needinfo?(nical.bugzilla)
See Also: → 1904276

Thanks. I filed bug 1904276 for the mozregression issue.

foxenesys : Could you try the two different builds posted in https://bugzilla.mozilla.org/show_bug.cgi?id=1897444#c12 , and see if your issue is solved by them?

Flags: needinfo?(dark.angel)

never mind. The builds dont fix the issue for other testers.

Flags: needinfo?(dark.angel)

We suspect this was regressed by a WebRender patch, so tagging as the WebRender component.

Blocks: gfx-triage
Severity: -- → S2
Component: Graphics → Graphics: WebRender
See Also: → 1904226
No longer blocks: gfx-triage

The fix for this is in bug 1897444.

Flags: needinfo?(nical.bugzilla)

(In reply to Nicolas Silva [:nical] from comment #22)

The fix for this is in bug 1897444.

I can confirm 128 nightly is working fine.

Assignee: nobody → nical.bugzilla
Status: NEW → RESOLVED
Closed: 2 months ago
Depends on: 1897444
Resolution: --- → FIXED
Target Milestone: --- → 129 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: