Closed Bug 1042168 Opened 10 years ago Closed 10 years ago

Overscroll colour is black when it should be the background colour

Categories

(Core :: Panning and Zooming, defect)

All
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1045520
2.1 S1 (1aug)
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- affected

People

(Reporter: cwiiis, Assigned: cwiiis)

References

Details

(Keywords: regression, Whiteboard: [systemsfe][tako])

[Blocking Requested - why for this release]: There are important reasons that we cannot have an overscroll area that doesn't match the background colour of the page.


Some time in the last week on master, the mechanism that determines the background colour of overscroll has been broken under certain situations.

STR:

1- Type 'google' into the homescreen search bar
2- Wait for a Google icon to appear and tap it
3- Wait for Google to load (which will load in an app wrapper)
4- Drag from the top to the bottom (i.e. try to scroll upwards) to initiate overscroll

Expected:

The area around the shrunken page is white.

Actual:

The area around the shrunken page is black.

If you navigate to google.com within the browser, the background colour is correct. Note, this is not an issue in 2.0 and appears to be a regression since last Thursday or so.
Bug 1022612 broke a bunch of stuff. I wouldn't be surprised if this was also fallout from that. In particular it made some unexpected changes to the layer tree (see bug 1041608).
So here's something interesting: when Chris originally let me know about this bug, I couldn't repro it on my build at the time, which was a build of Thursday's trunk.

I then pulled Gecko only (what I usually do when I pull), rebuilt, and still couldn't repro.

Just to be sure, I thought I'd pull the entire B2G repo and rebuild again, and now I see the problem.

Does this suggest that this is in fact somehow a Gaia regression? (Possibly from earlier than Thursday, since I hadn't pulled the whole B2G, and thus Gaia, since some time earlier.)
QA Contact: pcheng
Confirmed: switching back to the Gaia revision I was using before I pulled, without changing Gecko, makes the problem go away again.

The Gaia revision with which I do not see the problem is:

commit 10f141af83815940d1bd2b00a05c4f2e0965a0e3
Merge: 47241b6 5af95a4
Author: Julien Wajsberg <felash@gmail.com>
Date:   Thu Jul 10 23:47:21 2014 +0200

Therefore, we are looking for a _Gaia_ regression window, between July 10 and today.
b2g-inbound regression window:

Last Working Environmental Variables:
Device: Flame
BuildID: 20140711071412
Gaia: 76d9c1c1d1e56fcecd0b01ba604587cf73cb66aa
Gecko: f87018e3d067
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First Broken Environmental Variables:
Device: Flame
Build ID: 20140711071921
Gaia: 5b33a1e4c82d57369ec6812177e477e308d538ce
Gecko: 07618025b80d
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First broken gecko & last working gaia - no repro
Gaia: 76d9c1c1d1e56fcecd0b01ba604587cf73cb66aa
Gecko: 07618025b80d

First broken gaia & last working gecko - repro
Gaia: 5b33a1e4c82d57369ec6812177e477e308d538ce
Gecko: f87018e3d067

Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/76d9c1c1d1e56fcecd0b01ba604587cf73cb66aa...5b33a1e4c82d57369ec6812177e477e308d538ce

Might have been caused by Bug 1033364?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Broken by 1033364 ?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(21)
I investigated this a bit. Turns out that the code introduced in bug 1014280 to draw backgound colors for overscrolled layers, does not draw a background in this case, neither before the Gaia change, nor after. 

As a result, what is underneath shows through in both cases. The difference the Gaia change made, is to "what is underneath": before is was white - which happened to be correct for this page - and now it's black.

The reason the code introduced in bug 1014280 is not drawing a background is that the mBackgroundColor we get form Layout here [1] is (0, 0, 0, 0). I will continue investigating why this is.

[1] http://mxr.mozilla.org/mozilla-central/source/layout/base/nsDisplayList.cpp?rev=bd9304ad42cb#819
So it turns out that the background color of google.com is transparent. Therefore, the expected behaviour is that whatever is underneath shows through.

The simplest solution would be to make sure the color of "what is underneath" is consistent between the Browser App and the Search Results - in other words, fix the regression on the Gaia side.
For completeness, the other approach would be to get Layout to choose a background color (for the purpose of overscrolling) in a more sophisticated way, so that it chooses 'white' instead of 'transparent' for this page. This might be tricky, and there are bound to be cases it won't cover.
(In reply to Botond Ballo [:botond] from comment #8)
> For completeness, the other approach would be to get Layout to choose a
> background color (for the purpose of overscrolling) in a more sophisticated
> way, so that it chooses 'white' instead of 'transparent' for this page. This
> might be tricky, and there are bound to be cases it won't cover.

Thanks for the investigation! Given the default UA background colour of white, I think we should just set a white background behind the browser iframe. I'll write a patch to do so.
Assignee: nobody → chrislord.net
Status: NEW → ASSIGNED
Flags: needinfo?(21)
Whiteboard: [systemsfe][tako]
Target Milestone: --- → 2.1 S1 (1aug)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
blocking-b2g: 2.1? → ---
You need to log in before you can comment on or make changes to this bug.