Rendering of pages and UI broken in latest Nightlies




21 days ago
19 days ago


(Reporter: David Ross, Unassigned)


({nightly-community, regression})

60 Branch
nightly-community, regression

Firefox Tracking Flags

(firefox60 affected)



(2 attachments)



21 days ago
Created attachment 8947776 [details]
Screenshot from 2018-02-02 12-16-59.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171226085105

Steps to reproduce:

Everyday use. Mostly containers. Open tabs. Surf. Awesome! Webrender NOT enabled.

Actual results:

Hit a bug where pages render unable to be read. Big black blocks (if I switch from Adwaita dark or regular). Top of page you can sometime see a CURSOR like white block/box that even flashes. Also affects tab rendering. 

Page refresh does nothing. Opening new container, or tab, sometimes fixes, sometimes not. (image attached is a Guardian article with a ghost memory of the new tab)

Expected results:

Normal page rendering.

mozregression incoming - I suspect introduced Feb 1 Nightly

Comment 1

21 days ago
Bug shown in Build ID 20180201220225 (reported in dev edition)

Comment 2

21 days ago
Created attachment 8947778 [details]


21 days ago
Keywords: nightly-community


21 days ago
Summary: rendering → Rendering of pages and UI broken in latest Nightlies

Comment 3

21 days ago
(In reply to David Ross from comment #1)
> Bug shown in Build ID 20180201220225 (reported in dev edition)

This should be the regression range. If you can further reduce it by bisection on inbound, that would help.
Severity: normal → major
Has Regression Range: --- → yes
status-firefox60: --- → affected
Component: Untriaged → Graphics
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → x86_64


21 days ago
Keywords: regression

Comment 4

21 days ago
Tried from 30th January, just in case. Pffft. Couldn't get it to replicate. Gave it a good minimum 30 mins each bisection.

Come back into the regular Nightly and there's been another update. Not seen it since. Touch wood.


21 days ago
Last Resolved: 21 days ago
Resolution: --- → WORKSFORME

Comment 5

20 days ago
Experienced this bug again this morning after rewaking laptop from sleep. Another update awaited to build id 20180202220135 and I've not experienced it again in over 3 hours of use.

Comment 6

19 days ago
Here is my experience with almost certainly the same bug. Sorry if this is done improperly -- this is my first bug report.

OS: 64-bit Linux / Linux 4.4.0-109-generic
Firefox: 57.0.4
Build ID: 20180104112904

Summary: Content does not display -- instead, the frame(?) is usually black. Causing the window to repaint sections paints one of (a) black, (b) white, or (c) the previous tab displayed in the window.

Steps to reproduce:
??? H E C K if I know how to trigger it in general right now. This is the first time this has happened.

Once it's triggered, I can bring up a window glitching out like this by opening a few new tabs.

Interacting with the window in ways that cause it to repaint sections include highlighting sections, opening up Inspector, scrolling, etc.

The glitching also affects the scrollbar on the side.

Screenshotting, using the Screenshot Node feature of the Inspector in Developer Tools, worked mostly as expected.
However, there are certain inconsistencies in rendering -- Youtube doesn't play, and pages render slightly differently (for some reason getting higher scores on the two HTML5 tests I tried, for whatever worth those are).

Also, screenshots from affected tabs save in UTC, not my local timezone.

I'm running multiple copies of Firefox right now, and this is the only one experiencing this issue.

When just opening new tabs, after a few different numbers at the beginning, every 4th tab exactly acts like this.
Possibly relevant:  "Web Content Processes: 4/4"

Possibly related bugs: (Maybe.) (Based on the "ironically, when I went to file a webcompat bug, it captured it fine, even though the screen was still black." and "some fraction of new tabs come up black", this seems to be the same. However, this bug is very different from the two others linked in the discussion. (Maybe.)

Comment 7

19 days ago
(I have pictures. They're also up on a thread on Mastodon, but I can't figure out how to add them here? I just created an account so it would make sense if I didn't have that capability, though...)

(Also, this glitch is currently affecting my browser, predictably, although I don't expect it to do so if I restart it. If anyone has some poking around they'd like me to do in an affected tab, I can.)

opt-in by default: WebRender is an opt-in feature
unavailable by runtime: Build doesn't include WebRender

Comment 8

19 days ago
Okay, I've restarted the browsing session (It was getting a bit memory-heavy in general, because I have bad browsing habits), and I can confirm that it did not continue when I started it up again. Hopefully the information given is useful, and I can still post the values of stuff in about:support and about:config for reference, and if it starts happening again maybe there'll be suggestions here if there are any more experiments I should run.

Good luck, people who actually know what they're doing when poking around the browser.
You need to log in before you can comment on or make changes to this bug.