966510 - [Vivo Meu App] The page covers only half of display

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[sarsenyev]

Attachment: 2014-01-31-14-55-21.png

Description:
When opening one of the pages only half of display is covered, another half appears black

Step to reproduce:
1) Updated Buri to BuildID: 20140127004002
2) Download the "Vivo Meu App" from Marketplace
3) Launch the installed app from the home screen
4) Select any category
5) Scroll down just a little any page
6) Go back to menu "Inicio"
7) Select "Cadastre-se" page

Actual:
Both pages cover only one half of the display

Expected:
The pages displayed fully and no black screen is seen

Device: Buri 1.3 MOZ
BuildID: 20140127004002
Gaia: 25a45a836a4a21a30f63fa7b544b42e8b781180a
Gecko: c40099a42c1f
Version: 28.0a2
Firmware Version: v1.2-device.cfg

Notes:
Repro frequency: 100%
See attached: screenshot

Comment 1

[sarsenyev]

The issue doesn't reproduce on 1.2 and 1.1

Comment 2

[J Zimbrick]

Regression Window:

Last Working Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20140116004002
Gaia: 423326d524d3807b3a7ef9cc10f34baf26a34b8c
Gecko: 1dd80f8faa2f
Version: 28.0a2
Base Image: V1.2-device.cfg

First Broken Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20140117004005
Gaia: a81ccdc53e45a6adeaae423e104e91bcc1e12b0e
Gecko: 2c033140eff4
Version: 28.0a2
Base Image: V1.2-device.cfg

Note: Only seems to occur when APZ is enabled.

Comment 3

[Jason Smith [:jsmith]]

https://github.com/mozilla-b2g/gaia/compare/423326d524d3807b3a7ef9cc10f34baf26a34b8c...a81ccdc53e45a6adeaae423e104e91bcc1e12b0e

Comment 4

[Jason Smith [:jsmith]]

http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=1dd80f8faa2f&tochange=2c033140eff4

Comment 5

[Preeti Raghunath(:Preeti)]

Milan

Can you please have this on your radar as well?

Comment 6

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Seems to works well for me on m-c/master. Milan do you have anything in mind that we may have forgot to uplift ?

Comment 7

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

If QA can reproduce that this works on master, can we get a fix window from master? It should help us find the thing that needs uplifting.

Comment 8

[J Zimbrick]

I'm still able to reproduce this issue on the latest central build with a Buri device. Issue reproduces exactly as stated in Comment 0.

Device: Buri v1.4 Mozilla RIL
BuildID: 20140206040203
Gaia: ac8a273809b5b160554e616bc5ef2d6fa026ce0e
Gecko: 1e9f169c9715
Version: 30.0a1
Base Image: V1.2-device.cfg

Note that this issue only occurs when APZ is enabled. I suspect that APZ may have been turned off when this was tested in Comment 6. 

I'm going to remove the regressionwindow-wanted tag for now.

Comment 9

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

Initial investigation makes me strongly suspect this is a dupe of bug 965389.

Comment 10

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

Unfortunately the suggestion at https://bugzilla.mozilla.org/show_bug.cgi?id=964517#c32 doesn't fix this issue. I will continue investigating.

Comment 11

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

Ok, so I don't know if this a dupe of bug 965389 anymore, but I'm suspecting it's a problem with the visibility computation in a nsDisplayScrollLayer. Specifically, if we have a nsDisplayScrollLayer whose contents take up less space than the full nsDisplayScrollLayer, the visibility reported for the nsDisplayScrollLayer is still the full area. This causes the problem when the <div> corresponding to the nsDisplayScrollLayer has a transparent background, because the stuff underneath which is supposed to show through doesn't show through (as it is treated as invisible).

I'm attempting to verify this now by updating the visibility computation code in nsDisplayScrollLayer to be more like that in nsDisplayWrapList (i.e. remove the part of aVisibleRegion that the children don't occupy). I don't know if this is a correct fix or not. Another fix might be to drop the nsDisplayScrollLayer somehow if the contents don't take up the full space (and hence scrolling is impossible).

Comment 12

[Timothy Nikkel (:tnikkel)]

Attachment: patch

This was caused by bug 951467. Bug 951467 made the bounds of scroll layer items be the whole scroll port, instead of the bounds of the contained content. But GetOpaqueRegion of the base class (nsDisplayWrapList) only looked at if the contained mList was marked opaque. So if the contained list happened to be opaque we removed it's region from the visible region. When the bounds of the scroll layer items corresponded to the bounds of the contained list this was at least correct at paint time, even though it could be made false by async scrolling afterwards. But when the bounds of the item are the scrollport this is incorrect even at paint time as we check if the contained list is opaque and then remove the scrollport from the visible region, even if the scrollport is much larger than the bounds of the contained content. So this fixes a very old problem that was less noticeable, and a new problem introduced by bug 951467 that is much more noticeable.

Comment 13

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

Can we have a test here pleeease?

Comment 14

[Timothy Nikkel (:tnikkel)]

Attachment: reftest

I had to enhance the reftest harness to set display ports on on-root scroll frames (bug 970250), but I wrote a reftest for this bug. It can land when bug 970250 is landed.

Comment 15

[Timothy Nikkel (:tnikkel)]

I pushed the fix without the reftest in the interest of getting this bug fixed sooner.
https://hg.mozilla.org/integration/mozilla-inbound/rev/2b457d4ab04e

Comment 16

[Timothy Nikkel (:tnikkel)]

Attachment: reftest

Comment 17

[Sylvestre Ledru [:Sylvestre]]

Regarding the tracking flags about firefox itself, is there a way to reproduce this bug with Firefox?

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/2b457d4ab04e

Comment 19

[Timothy Nikkel (:tnikkel)]

(In reply to Sylvestre Ledru [:sylvestre] from comment #17)
> Regarding the tracking flags about firefox itself, is there a way to
> reproduce this bug with Firefox?

Metro Firefox and b2g is probably where this will show up most. I haven't tried to reproduce on metro, but I'm pretty sure a testcase could be crafted, like say the reftest in this bug.

Comment 20

[Timothy Nikkel (:tnikkel)]

Comment on attachment 8372888 [details] [diff] [review]
patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 951467
User impact if declined: rendering will look wrong in some cases with scrollable elements or subdocuments on metro and b2g
Testing completed (on m-c, etc.): just landed on m-c
Risk to taking this patch (and alternatives if risky): the old behaviour was just wrong (claiming an region was opaquely covered when it was not)
String or IDL/UUID changes made by this patch: none

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/faaee1aad9f9
https://hg.mozilla.org/releases/mozilla-beta/rev/4b2f78c2d884

Comment 22

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/4b2f78c2d884

Comment 23

[Timothy Nikkel (:tnikkel)]

pushed the reftest
https://hg.mozilla.org/integration/mozilla-inbound/rev/9a268a4c902b

Comment 24

[Timothy Nikkel (:tnikkel)]

reftest was orange on android, I think because android doesn't handle displayports on scroll frames other than the root, so I just turned it off on Android. Testing this on desktop is enough to catch this problem, and it remains turned on on b2g.
https://hg.mozilla.org/integration/mozilla-inbound/rev/5775ed3239fa

Comment 25

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/9a268a4c902b
https://hg.mozilla.org/mozilla-central/rev/5775ed3239fa