From: https://www.reddit.com/r/firefox/comments/e7d3pi/weekly_nightly_discussion_for_20191207_20191213/fa9p2ax/

The browser itself does open (after clicking the icon many times...) but it only shows a black background. I can't access any websites or even "about:config" etc. Nothing.

Regressed by Bug 1592509 - Enable gfx.webrender.compositor by default on Windows r=gw

The issue persists in safe mode, which is surprising to me.

Driver date seems old. Asif is it possible to update graphic driver?

Description: Intel(R) HD Graphics 620
Vendor ID: 0x8086
Device ID: 0x5916
Driver Version: 21.20.16.4550
Driver Date: 11-11-2016

We might need to block webrender os compositor when driver is very old.

(In reply to Asif Youssuff from comment #0)

Regressed by Bug 1592509 - Enable gfx.webrender.compositor by default on Windows r=gw

The issue persists in safe mode, which is surprising to me.

Hmm, it is weird.

We could change the blocklist for the broken 6293 driver from == to be <=, which would also cover this case here?

(In reply to Glenn Watson [:gw] from comment #5)

We could change the blocklist for the broken 6293 driver from == to be <=, which would also cover this case here?

Bug 1602511 blocks only HD 520 device. It belongs to skylake. HD 620 belongs to Kaby Lake. Then we need to thinks about range of block devices. Can we block all intel devices before 6293(Driver Date: 9-26-2018)?

I think it's reasonable to block all Intel devices <= 6293 driver for now. We can always relax that in future.

Yea, it is reasonable for now. I take this bug.

https://hg.mozilla.org/mozilla-central/rev/70bf1a050c7b

Sotaro, FWIW, the user installed V22.20.16.4836.04 from https://www.asus.com/Laptops/ASUS-ZenBook-UX430UQ/HelpDesk_Download/ and they still see the issue in their original profile, but don't see the issue for builds run from mozregression not reusing their profile from 2019-12-08 to today.

It still isn't clear to me what is going on, because I'm not sure whether a clean profile would have resolved the issue to begin with -- or why even if they were using their possibly bad profile would have shown the webrender compositor commit being the regressing bug.

Just wanted to throw this in here for completeness even though you cancelled my NI.

I wonder if this was actually caused by https://bugzilla.mozilla.org/show_bug.cgi?id=1603207, which is now in the landing queue (with that bug, if the user profile had gfx.webrender.picture-caching disabled, nothing will be drawn in compositor mode). Probably unlikely to be the cause, but it might explain it if the behavior varies based on profile settings.

(In reply to Asif Youssuff from comment #12)

Sotaro, FWIW, the user installed V22.20.16.4836.04 from https://www.asus.com/Laptops/ASUS-ZenBook-UX430UQ/HelpDesk_Download/ and they still see the issue in their original profile, but don't see the issue for builds run from mozregression not reusing their profile from 2019-12-08 to today.

Thanks. If the problem does not happen with mozregression, it might be a different problem than WebRender os compositor. And comment 0 said that the problem also happen in safe mode, then I wonder if user profile might be broken.

In safe mode, only BasicCompositor should be used. Gecko do not try to instantiate WebRender.

== Change summary for alert #24466 (as of Thu, 12 Dec 2019 11:08:47 GMT) ==

Improvements:

32% tscrollx windows10-64-shippable-qr opt e10s stylo 1.17 -> 0.80
30% tscrollx windows10-64-shippable-qr opt e10s stylo 1.23 -> 0.86
24% tart windows10-64-shippable-qr opt e10s stylo 3.45 -> 2.63

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=24466

This probably means that our tests are no longer testing what they need to test...

Hmm.

I am going to backout the patch for now because of comment 16 and the bug seemed not be related to WR compositor by comment 14.

https://hg.mozilla.org/mozilla-central/rev/883cf2212e46

WR compositor is going to be re-enabled on nightly next year.

Bug 1604088 disabled the WR compositor, so Fx73 shouldn't be affected at this point. Should this bug be changed to blocking bug 1602073 now?

Backout alert
== Change summary for alert #24514 (as of Wed, 18 Dec 2019 09:38:50 GMT) ==

Regressions:

57% tscrollx windows10-64-shippable-qr opt e10s stylo 0.78 -> 1.22
41% tart windows10-64-shippable-qr opt e10s stylo 2.46 -> 3.48
26% tscrollx windows10-64-shippable-qr opt e10s stylo 0.97 -> 1.22

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=24514

https://downloadcenter.intel.com/download/29335/Intel-Graphics-Windows-10-DCH-Drivers

Mozilla should tell users to update to Intel 26.20.100.7755 driver or later versions if possible.

Does this seem like it is still an issue?

Jessie, the user reports it has been fixed in the latest Nightly: https://www.reddit.com/r/firefox/comments/e7d3pi/weekly_nightly_discussion_for_20191207_20191213/fhivx2l/