Open Bug 1927076 Opened 1 year ago Updated 1 year ago

Blocklist update from bug 1923697 seems to affect windows 11

Categories

(Core :: Graphics: WebRender, defect, P3)

defect

Tracking

()

Tracking Status
firefox-esr128 --- unaffected
firefox131 --- unaffected
firefox132 --- unaffected
firefox133 --- wontfix
firefox134 --- fix-optional

People

(Reporter: emilio, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

As per bug 1926862, it seems the blocklist from bug 1923697 incorrectly affects windows 11...

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

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

For more information, please visit BugBot documentation.

Flags: needinfo?(sotaro.ikeda.g)

This appears to be as intended, because we don't attempt to differentiate between Windows 10 and Windows 11. We read the OSVERSIONINFOA structure which maxes out at dwMajorVersion 10. When we read that, we also capture the build number, which can tell us if the version is actually windows 11, but we only use this to determine if the build is a "recent" Windows 10 build. So, this is operating as designed, which of course we can change.

Some questions:

  1. Do we have any evidence this is fixed in Windows 11? Probably hard to collect evidence with the blocklist in place...
  2. Should we create a OperatingSystem::Windows11 enum for use in the blocklist, such that this hardware is no longer blocked in Windows 11?
  3. Should we change the blocklist entry for this hardware to NotRecentWindows10? I can't tell from reading the about:support in Bug 1923697 if this would correctly affect the reporter's hardware.

Will discuss in triage.

Blocks: gfx-triage

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

Flags: needinfo?(sotaro.ikeda.g)

Taking this out of triage while we come up with a general plan for narrowing existing blocklist entries, and making it possible to ignore the blocklist for testing purposes.

No longer blocks: gfx-triage, gfx-blocklist
See Also: → 1928521
Severity: -- → S3
Priority: -- → P3

Hey Brad, I am the REO for Fx133 and I am checking in because this bug is marked affecting Fx133. The priority and severity indicate it's not critical to be fixed in Fx133, right? Can you confirm? If not, then I would take off the release tracking flag. Thanks!

Flags: needinfo?(bwerth)

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #5)

Hey Brad, I am the REO for Fx133 and I am checking in because this bug is marked affecting Fx133. The priority and severity indicate it's not critical to be fixed in Fx133, right? Can you confirm? If not, then I would take off the release tracking flag. Thanks!

It is not critical, thank you for asking.

Flags: needinfo?(bwerth)
No longer blocks: gfx-blocklist
You need to log in before you can comment on or make changes to this bug.