Closed Bug 966510 Opened 6 years ago Closed 6 years ago

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

Categories

(Core :: Layout, defect)

28 Branch
ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla30
blocking-b2g 1.3+
Tracking Status
firefox28 + fixed
firefox29 + fixed
firefox30 + fixed
b2g18 --- unaffected
b2g-v1.2 --- unaffected
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed

People

(Reporter: sarsenyev, Assigned: tnikkel)

References

Details

(Keywords: regression, Whiteboard: dogfood1.3)

Attachments

(3 files, 1 obsolete file)

Attached image 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
The issue doesn't reproduce on 1.2 and 1.1
blocking-b2g: --- → 1.3?
Component: Preinstalled B2G Apps → Panning and Zooming
Product: Tech Evangelism → Core
Version: unspecified → 28 Branch
No longer blocks: b2g-guiameu
QA Contact: jzimbrick
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.
Blocks: gaia-apzc
Milan

Can you please have this on your radar as well?
blocking-b2g: 1.3? → 1.3+
Flags: needinfo?(milan)
Flags: needinfo?(milan)
Assignee: nobody → bugmail.mozilla
Whiteboard: dogfood1.3 → dogfood1.3, [ETA: 2/25]
Seems to works well for me on m-c/master. Milan do you have anything in mind that we may have forgot to uplift ?
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.
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.
Initial investigation makes me strongly suspect this is a dupe of bug 965389.
Unfortunately the suggestion at https://bugzilla.mozilla.org/show_bug.cgi?id=964517#c32 doesn't fix this issue. I will continue investigating.
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).
Attached patch patchSplinter Review
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.
Assignee: bugmail.mozilla → tnikkel
Status: NEW → ASSIGNED
Attachment #8372888 - Flags: review?(roc)
No longer blocks: gaia-apzc
Component: Panning and Zooming → Layout
Can we have a test here pleeease?
Attached patch reftest (obsolete) — Splinter Review
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.
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
Attached patch reftestSplinter Review
Attachment #8373240 - Attachment is obsolete: true
Regarding the tracking flags about firefox itself, is there a way to reproduce this bug with Firefox?
https://hg.mozilla.org/mozilla-central/rev/2b457d4ab04e
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: dogfood1.3, [ETA: 2/25] → dogfood1.3
Target Milestone: --- → mozilla30
(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 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
Attachment #8372888 - Flags: approval-mozilla-beta?
Attachment #8372888 - Flags: approval-mozilla-aurora?
Attachment #8372888 - Flags: approval-mozilla-beta?
Attachment #8372888 - Flags: approval-mozilla-beta+
Attachment #8372888 - Flags: approval-mozilla-aurora?
Attachment #8372888 - Flags: approval-mozilla-aurora+
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
You need to log in before you can comment on or make changes to this bug.