800041 - Amazon product pages completely painted with large white blocks

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[Tyler Downer [He/Him]]

This may be bug 792006, but when you visit a product page in Firefox nightly for mobile, you will see a large White box blocking the content until you scroll. This only happens on the mobile version of the site (tested on a droidx and Galaxy S2, Nexus 7 did not show this behavior.

Comment 1

[Aaron Train [:aaronmt]]

Do we know if it's mobile Amazon or Amazon proper? Unfortunately, searches from the search-engine take you to the desktop site, but heading directly to amazon.com takes you to the mobile site.

Comment 2

[[:Cww]]

Mobile site:

http://www.amazon.com/gp/aw/d/1449410243/ref=aa_ri_books_top_1?pi=SL75

Comment 3

[Aaron Train [:aaronmt]]

Confirmed. Easy to reproduce

adb shell am start -a android.intent.action.VIEW -n org.mozilla.fennec -d "http://www.amazon.com/Tron-Original-Classic-Five-Disc-Blu-ray/dp/B004K4N64E/"

Comment 4

[Brad Lassey [:blassey] (use needinfo?)]

note: you need "/.App" after fennec in the line that Aaron posted

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

I can reproduce this too on GN Nightly. Does this happen on Aurora? Let's get a regression range.

Comment 6

[Benoit Girard (:BenWa)]

Thanks for the steps, I've seen this but not been able to reproduce reliably before.

It would be nice to know if 18/17/16 are affected.

Comment 7

[Benoit Girard (:BenWa)]

Last good nightly: 2012-09-16
First bad nightly: 2012-09-17

Comment 8

[Benoit Girard (:BenWa)]

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-09-16&enddate=2012-09-17

Comment 10

[Benoit Girard (:BenWa)]

Matt this is a regression from bug 788044. Got time to take this?

Comment 11

[Matt Woodrow (:mattwoodrow)]

Not really :)

I can reproduce this, don't have any ideas about why it's a mobile only bug.

Chris: Does this look familiar to you at all? Something to do with fixed position content maybe? (Not that I can see any).

If anyone can find an equivalent bug on desktop I should be able to get to this fairly quickly, debugging it on mobile will take longer.

Comment 12

[Chris Lord [:cwiiis]]

I've only seen this since DLBI, though it may be unrelated in terms of what actually causes it. Does seem to be a duplicate of bug 792006, do we need to have more than one bug for this?

As for bug 788044 being a possible cause, I had a fix for problems this caused in bug 794686, but this code has entirely changed since DLBI... Is it possible the same mistake is being made elsewhere? It would explain why this is mobile-only, as we very rarely render untransformed (scale transform).

Comment 13

[Aaron Train [:aaronmt]]

Attachment: Galaxy Note (Nightly, 10/18) - Screenshot

Comment 14

[Aaron Train [:aaronmt]]

Matt, I've filed another case in bug 804586. Aurora and Nightly are affected, and is it simple to reproduce.

Comment 15

[(no longer active)]

Not sure why this is marked as tracking-fennec19, as it also affects 18 which will be in Beta in about three weeks.

Matt, can we perhaps back out bug 788044?  I hit this bug on mobile several times every single day and sometimes the browser's rendering is unusable...  I'd really prefer if we address this regression sooner (by a backout if needed.)  What do you think?

Comment 16

[Matt Woodrow (:mattwoodrow)]

Attachment: Set the correct reference frame for nsDisplayScrollLayer

This was.. annoying.

The code assumes that nsDisplayTransform is always the outermost display item for a given frame, and any other items for the same frame should have itself as the reference frame. Neither of these things are true for nsDisplayScrollLayer.

Things get even more fun once we merge multiple scroll layers together, and the nsDisplayScrollLayer for the page gets set a reference frame that is way down the frame tree.

I'd like to add a way of checking for this error, it seems much to easy to get caught by. 
My best idea so far is to walk all child display items looking for an nsDisplayTransform for the same frame, and assert that mReferenceFrame != mFrame.
Not sure where we can check this from though,the nsDisplayItem constructor will be too early.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Add a debug-only pass over the display list tree validating our invariants?

Comment 18

[Matt Woodrow (:mattwoodrow)]

Attachment: Check for this problem

This assertion would have caught the bug

Comment 19

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/bbfa842d5f5e

Landed the fix. The assertion caught a few other issues, working on them now.

Comment 20

[Matt Woodrow (:mattwoodrow)]

Attachment: More robust reference frame code

Comment 21

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8bffa268afd8

Comment 22

[Phil Ringnalda (:philor)]

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/d9a3c895f98c - your assertion was firing three times for bugs/745934-1.html, which may be just what you want, but it wasn't annotated as being just what you want.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/bbfa842d5f5e

Comment 24

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/56ea8204864d

Comment 25

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/56ea8204864d

Comment 26

[Aaron Train [:aaronmt]]

This needs Aurora uplift.

Comment 29

[Matt Woodrow (:mattwoodrow)]

Comment on attachment 674522 [details] [diff] [review]
Set the correct reference frame for nsDisplayScrollLayer

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 788044
User impact if declined: Multiple high profile sites broken.
Testing completed (on m-c, etc.): Been on m-c for 2 days, confirmed that it fixes the issues.
Risk to taking this patch (and alternatives if risky): Should be fairly low risk, changes the visibility calculation code  for content that involves transforms.
String or UUID changes made by this patch: None

Comment 31

[bhavana bajaj [:bajaj]]

Comment on attachment 674522 [details] [diff] [review]
Set the correct reference frame for nsDisplayScrollLayer

Approving for aurora as its a significant user facing issue and the patch is low-risk .

Comment 32

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/87bb99d02f1c

Comment 34

[Paul Feher]

Verified on:
Build: Aurora 18.0a2 (2012-11-19)
Device: Samsung  Galaxy R
OS: Android 2.3.4