1260534 - Checkerboarding in reader view is white instead of page background color

Status: RESOLVED DUPLICATE of bug 1294857

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

Description

[Mark Capella [:capella]]

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:
https://www.dropbox.com/s/90b21ohz3nz7uu0/readerView_Scroll_Issue.mp4?dl=0

Not sure if this is ReaderView or APZ component, I haven't noticed this on other pages with normal dark themes like ArsTechnica.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

This looks kind of like checkerboarding where we don't detect the background color properly. Probably more APZ than Reader View.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

I could only repro on Nightly.

Comment 3

[Randall Barker [:rbarker]]

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.

Comment 4

[Randall Barker [:rbarker]]

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.

Comment 5

[Mark Capella [:capella]]

I found a non-readerView page where this is easily visible:
https://www.mozilla.org/en-US/firefox/developer/

(Dark blue background)

Comment 6

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 7

[Mark Capella [:capella]]

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.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 10

[Mark Capella [:capella]]

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 TheHill.com loading in a background tab.

[0] http://www.americanthinker.com/blog/2016/06/can_the_trump_campaign_reboot_and_win.html

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Ok, thanks. I guess we still need to track down the background color issue.

Comment 12

[Randall Barker [:rbarker]]

This should be fixed by Bug 1294857.

Comment 13

[Randall Barker [:rbarker]]

I'm going to mark this one as the duplicate since I posted the patch to Bug 1294857.