Closed Bug 1260534 Opened 8 years ago Closed 8 years ago

Checkerboarding in reader view is white instead of page background color


(Firefox for Android Graveyard :: Toolbar, defect, P3)

48 Branch


(firefox47 unaffected, firefox48 fix-optional, firefox49 fix-optional, firefox50 affected)

Tracking Status
firefox47 --- unaffected
firefox48 --- fix-optional
firefox49 --- fix-optional
firefox50 --- affected


(Reporter: capella, Unassigned)




Basically, if you're viewing with "Dark" theme and fling / scroll fast, the page doesn't update smoothly ... stuttering before updating content/background color.

For ex:

Not sure if this is ReaderView or APZ component, I haven't noticed this on other pages with normal dark themes like ArsTechnica.
This looks kind of like checkerboarding where we don't detect the background color properly. Probably more APZ than Reader View.
Component: Reader View → Graphics, Panning and Zooming
I could only repro on Nightly.
Version: unspecified → 48 Branch
I did a little investigating into this and found two issues.

1) The reader mode background color when using dark theme is "transparent" instead of the expected format of rgb(X,X,X) which causes it to default to Color.WHITE. This happens in both C++APZ and JPZ.

2) C++APZ check boards far worse than JPZ when viewing the reader page. This makes the issue much more obvious when using C++APZ.

For issue #1, someone needs to figure out when we are getting "transparent" instead of rbd(34,34,34) (i.e. #222222 as specified in the CSS file aboutReader.css).

For issue #2, we should investigate why C++APZ checker boarding is so much worse than JPZ when in reader mode. The page is so simple there we really should never be checker boarding.
After a little more digging, it looks like the background color is set in js and is done after the DOMContentLoaded event has been dispatched. It does not appear that Fennec has a mechanism for detecting when the background color of a page changes.
I found a non-readerView page where this is easily visible:

(Dark blue background)
The excessive checkerboards might be because of bug 1263347. We can use this bug to track the background color issue, if it's something we can actually fix.
I'd seen a mail from snorp on mobile-firefox-dev the other day,

"I just pushed a change that will cause us to checkerboard differently, and Anthony and I want to collect feedback from folks ...'

He didn't mention the bug #, I'm guessing (?)
Bug 1178376 - Fade in tiles that had placeholders before when we aren't using low-precision buffers

In any case, this bug seems to be better. Though I can still observe white flash / flickers if a work hard to fast-scroll.
Are you still able to reproduce badness in today's nightly? I suspect bug 1262807 will have improved the situation a lot. On my Z3C I can't checkerboard this page any more.
Flags: needinfo?(markcapella)
After rebuilding and testing just now using [0] on my 5X, I still see the checkerboarding. In addition, I see it on other pages such as Ars Technica and Physics World.

I had a hard time repro-ing on my N7, as going into ReaderView on a tablet page lengthy enough to allow easy scrolling took a little research.

I'm able to aggravate the situation it seems (?), by simultaneously starting a complex page like loading in a background tab.

Flags: needinfo?(markcapella)
Ok, thanks. I guess we still need to track down the background color issue.
Priority: -- → P3
Summary: Page flinging in ReaderView lags screen updates → Checkerboarding in reader view is white instead of page background color
This should be fixed by Bug 1294857.
I'm going to mark this one as the duplicate since I posted the patch to Bug 1294857.
Closed: 8 years ago
Resolution: --- → DUPLICATE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.