Closed Bug 966510 Opened 6 years ago Closed 6 years ago
[Vivo Meu App] The page covers only half of display
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
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.
Milan Can you please have this on your radar as well?
blocking-b2g: 1.3? → 1.3+
6 years ago
6 years ago
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).
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
Attachment #8372888 - Flags: review?(roc) → review+
Can we have a test here pleeease?
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
Regarding the tracking flags about firefox itself, is there a way to reproduce this bug with Firefox?
(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
pushed the reftest https://hg.mozilla.org/integration/mozilla-inbound/rev/9a268a4c902b
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.