Closed
Bug 966510
Opened 11 years ago
Closed 11 years ago
[Vivo Meu App] The page covers only half of display
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: sarsenyev, Assigned: tnikkel)
References
Details
(Keywords: regression, Whiteboard: dogfood1.3)
Attachments
(3 files, 1 obsolete file)
18.54 KB,
image/png
|
Details | |
1.79 KB,
patch
|
roc
:
review+
Sylvestre
:
approval-mozilla-aurora+
Sylvestre
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
3.32 KB,
patch
|
Details | Diff | Splinter Review |
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
status-b2g18:
--- → unaffected
status-b2g-v1.2:
--- → unaffected
status-b2g-v1.3:
--- → affected
Keywords: regression,
regressionwindow-wanted
Updated•11 years ago
|
blocking-b2g: --- → 1.3?
Component: Preinstalled B2G Apps → Panning and Zooming
Product: Tech Evangelism → Core
Version: unspecified → 28 Branch
Updated•11 years ago
|
No longer blocks: b2g-guiameu
Updated•11 years ago
|
QA Contact: jzimbrick
Comment 2•11 years ago
|
||
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.
Keywords: regressionwindow-wanted
Comment 3•11 years ago
|
||
Comment 4•11 years ago
|
||
Comment 5•11 years ago
|
||
Milan
Can you please have this on your radar as well?
blocking-b2g: 1.3? → 1.3+
Flags: needinfo?(milan)
Updated•11 years ago
|
Flags: needinfo?(milan)
Updated•11 years ago
|
Assignee: nobody → bugmail.mozilla
Whiteboard: dogfood1.3 → dogfood1.3, [ETA: 2/25]
Comment 6•11 years ago
|
||
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•11 years ago
|
||
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.
Keywords: regressionwindow-wanted
Comment 8•11 years ago
|
||
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.
Keywords: regressionwindow-wanted
Comment 9•11 years ago
|
||
Initial investigation makes me strongly suspect this is a dupe of bug 965389.
Comment 10•11 years ago
|
||
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•11 years ago
|
||
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).
Assignee | ||
Comment 12•11 years ago
|
||
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 | ||
Updated•11 years ago
|
Updated•11 years ago
|
status-b2g-v1.4:
--- → affected
status-firefox28:
--- → affected
status-firefox29:
--- → affected
status-firefox30:
--- → affected
Attachment #8372888 -
Flags: review?(roc) → review+
Can we have a test here pleeease?
Assignee | ||
Comment 14•11 years ago
|
||
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.
Assignee | ||
Comment 15•11 years ago
|
||
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
Assignee | ||
Comment 16•11 years ago
|
||
Attachment #8373240 -
Attachment is obsolete: true
Comment 17•11 years ago
|
||
Regarding the tracking flags about firefox itself, is there a way to reproduce this bug with Firefox?
Comment 18•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: dogfood1.3, [ETA: 2/25] → dogfood1.3
Target Milestone: --- → mozilla30
Assignee | ||
Comment 19•11 years ago
|
||
(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.
Assignee | ||
Comment 20•11 years ago
|
||
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?
Updated•11 years ago
|
Attachment #8372888 -
Flags: approval-mozilla-beta?
Attachment #8372888 -
Flags: approval-mozilla-beta+
Attachment #8372888 -
Flags: approval-mozilla-aurora?
Attachment #8372888 -
Flags: approval-mozilla-aurora+
Comment 21•11 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/faaee1aad9f9
https://hg.mozilla.org/releases/mozilla-beta/rev/4b2f78c2d884
Flags: in-testsuite?
Comment 22•11 years ago
|
||
Updated•11 years ago
|
Assignee | ||
Comment 23•11 years ago
|
||
pushed the reftest
https://hg.mozilla.org/integration/mozilla-inbound/rev/9a268a4c902b
Assignee | ||
Comment 24•11 years ago
|
||
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•11 years ago
|
||
Updated•11 years ago
|
status-b2g-v1.3T:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•