Closed Bug 1147194 Opened 11 years ago Closed 11 years ago

[Cost Control] Settings page displays a black screen

Categories

(Core :: Graphics: Layers, defect)

37 Branch
ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla40
blocking-b2g 2.2+
Tracking Status
firefox38 --- wontfix
firefox39 --- wontfix
firefox40 --- fixed
b2g-v2.2 --- verified
b2g-master --- verified

People

(Reporter: ychung, Assigned: mstange)

References

()

Details

(Keywords: regression, verifyme, Whiteboard: [3.0-Daily-Testing])

Attachments

(5 files, 4 obsolete files)

Description: Settings page displays a black screen after the mobile data usage is changed (ex. going on a website). Pre-requisite: Data connection is enabled. Repro Steps: 1) Update a Flame to 20150324010202. 2) Open Usage app, and go through the FTU steps. 3) Long-press the home button to bring out the task manager. 4) Close the Usage app. 5) Open Browser, and go to any website. 6) Press the home button to return to the homescreen, and open Usage app again. 7) Select the settings icon. Actual: A black screen appears below the status bar. Expected: The settings page appears properly. Environmental Variables: Device: Flame 3.0 (KK, 319mb, full flash) Build ID: 20150324010202 Gaia: efebbafd12fc42ddcd378948b683a51106517660 Gecko: 840cfd5bc971 Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b Version: 39.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0 Repro frequency: 5/5 See attached: video, logcat https://youtu.be/TbclvTM5xsk
This issue does NOT reproduce on Flame 2.2. Result: The settings page appears properly. Device: Flame 2.2 (KK, 319mb, full flash) Build ID: 20150324002504 Gaia: 014d38f7ad3912b8b33cb08ce7535a5dc5aced59 Gecko: 7a9f2a248e57 Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429 Version: 37.0 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
[Blocking Requested - why for this release]: Nominating 3.0? since this a regression from 2.2 and leads to a broken settings page. Let's get a regression window.
blocking-b2g: --- → 3.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Contact: ychung
Mozilla-inbound Regression Window: Last Working Environmental Variables: Device: Flame 3.0 BuildID: 20150316231229 Gaia: 4868c56c0a3b7a1e51d55b24457e44a7709ea1ae Gecko: a80676087e0a Version: 39.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0 First Broken Environmental Variables: Device: Flame 3.0 BuildID: 20150316231828 Gaia: 4868c56c0a3b7a1e51d55b24457e44a7709ea1ae Gecko: 18e46b2b3315 Version: 39.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0 Last Working Gaia First Broken Gecko: Issue DOES reproduce Gaia: 4868c56c0a3b7a1e51d55b24457e44a7709ea1ae Gecko: 18e46b2b3315 First Broken Gaia Last Working Gecko: Issue does NOT reproduce Gaia: 4868c56c0a3b7a1e51d55b24457e44a7709ea1ae Gecko: a80676087e0a http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a80676087e0a&tochange=18e46b2b3315 possibly caused by bug 1135907
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Contact: ychung
David, could you take a look at this please? This looks to be caused by the landing for bug 1135907.
Blocks: 1135907
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(dvander)
triage: major regression. but we should revisit if the 3.0 scope has changed
blocking-b2g: 3.0? → 3.0+
This reproduce on B2G 2.2 20150409002503 on Flame (v18D).
blocking-b2g: 3.0+ → 2.2?
triage: blocking.
blocking-b2g: 2.2? → 2.2+
Based on regression window.
Component: Gaia::Cost Control → Graphics: Layers
Product: Firefox OS → Core
Version: unspecified → 37 Branch
Flags: needinfo?(dvander)
Flags: needinfo?(dvander)
There is a simple reproduce way: 1. Let the Mobile usage more than 0KB. 2. Open the Usage app and the open the setting page. Wifi usage will not cause this problem! I think the regression window is wrong because I tried "Gecko: a80676087e0a" also has this problem. That is because the reproduce way must be Mobile. I will look at this bug.
Assignee: nobody → etlin
Flags: needinfo?(dvander)
Yeojin, I found the regression changeset should be Gecko:9d08f61b03f9. Can you help me confirm the changeset? Issue DOES reproduce: Gaia: 4868c56c0a3b7a1e51d55b24457e44a7709ea1ae Gecko: 9d08f61b03f9 Issue does NOT reproduce: Gaia: 4868c56c0a3b7a1e51d55b24457e44a7709ea1ae Gecko: c7dd154a7e83
Flags: needinfo?(ychung)
That new regression range seems more likely to be correct based on the symptoms described.
Blocks: 1141595
No longer blocks: 1135907
Could you provide the build ID from the pvt server? I cannot find those changeset just by that. And can you specify what branch those are? Can you also provide me the pushlog please?
Flags: needinfo?(ychung) → needinfo?(etlin)
Yeojin, the push log range should be from Gecko:24653749f9e0 to Gecko:9d08f61b03f9. http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=24653749f9e0&tochange=9d08f61b03f9 The branch is mozilla-center, and the build ID 20150317073344 is the first version which can reproduce. The build ID 20150317010203 should be the last version does NOT reproduce. it's possibly caused by bug 1141595. Please check again, Thanks.
Assignee: etlin → nobody
Flags: needinfo?(etlin) → needinfo?(ychung)
Dear Ethan, I was unable to reproduce on the central build that you pointed as first broken build: Environmental Variables: Device: Flame 3.0 BuildID: 20150317073344 Gaia: 738987bd80b0ddb4ccf853855388c2627e19dcc1 Gecko: 008b3f65a7e0 Version: 39.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0 I did not see the black screen, and the settings page appears fine. And I am still unable to find the correct builds with the gecko changeset. I'm sorry but I don't think I am able to help you confirming the issue anymore.
Flags: needinfo?(ychung)
I backed out the patches in bug 1141595 and the black screen problem is solved. With the patch, there is an additional container layer which contains a black paintedlayer. That should be the hoisted ScrollInfoLayer. Markus, can you take a look at this please?
Flags: needinfo?(mstange)
Ethan, is it possible that there are two black screen bugs here, with different regression ranges? I'm assuming that you tested your steps from comment 9 in order to get the regression range in comment 10, and Yeojin used the steps from comment 0 in order to get the regression range in comment 3.
Flags: needinfo?(mstange) → needinfo?(etlin)
Markus, please unassign this from you if it turns out you don't have an action on it.
Assignee: nobody → mstange
(In reply to Markus Stange [:mstange] from comment #16) > Ethan, is it possible that there are two black screen bugs here, with > different regression ranges? I'm assuming that you tested your steps from > comment 9 in order to get the regression range in comment 10, and Yeojin > used the steps from comment 0 in order to get the regression range in > comment 3. Markus, the two kinds of test steps is same. The steps in comment 9 is just a simple way to get the same result. I also tried to back out the patches in bug 1135907 which is found in comments 3, and I used exactly the same steps in comment1. But the black screen still appeared. So I think there should be only one black screen bug.
Flags: needinfo?(etlin)
Attached file asserting testcase
Attached patch patch (obsolete) — Splinter Review
Attachment #8598953 - Flags: review?(tnikkel)
The wrapping transform can turn inactive because at the time that we determine its layer state, the nsDisplayScrollInfoLayer's layer state is still LAYER_NONE, because its mHoisted is false. We only call MarkHoisted on it once we process the item in ContainerState::ProcessDisplayItems, and by then it's already too late to make the wrapping transform active.
Attached patch rewrite hoisting a third time (obsolete) — Splinter Review
As discussed on IRC. This looks much better.
Attachment #8598953 - Attachment is obsolete: true
Attachment #8598953 - Flags: review?(tnikkel)
Attachment #8599990 - Flags: review?(tnikkel)
Comment on attachment 8599990 [details] [diff] [review] rewrite hoisting a third time Review of attachment 8599990 [details] [diff] [review]: ----------------------------------------------------------------- Actually, let me try to come up with some better method names first.
Attachment #8599990 - Flags: review?(tnikkel)
Attachment #8599990 - Attachment is obsolete: true
Attachment #8600005 - Flags: review?(tnikkel)
Attachment #8600005 - Flags: review?(tnikkel) → review+
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Please request b2g37 approval on this patch when you get a chance.
Flags: needinfo?(mstange)
Comment on attachment 8600005 [details] [diff] [review] rewrite hoisting a third time NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 1141595 User impact if declined: intermittent brief black screens Testing completed: a little manual testing Risk to taking this patch (and alternatives if risky): not particularly risky, has baked for weeks now String or UUID changes made by this patch: none
Flags: needinfo?(mstange)
Attachment #8600005 - Flags: approval-mozilla-b2g37?
Flags: needinfo?(npark)
No-Jun, any manual testing you want to do?
Comment on attachment 8600005 [details] [diff] [review] rewrite hoisting a third time Approving and requesting QA verify after patch landed on 2.2
Attachment #8600005 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
Keywords: verifyme
sure, Will check it out on master today
Flags: needinfo?(npark)
This needs rebasing for b2g37 uplift.
Flags: needinfo?(mstange)
This issue is verified fixed on the latest 3.0 Nightly Flame build. Leaving the verifyme tag for when this fix gets uplifted to 2.2. Actual Results: The settings screen looks as expected. Environmental Variables: Device: Flame 3.0 BuildID: 20150528010203 Gaia: 05380df3158fa39e1dde1687c0bf11a71f8c6868 Gecko: baa9c64fea6f Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67 Version: 41.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Attached patch merged to b2g37 (obsolete) — Splinter Review
Giving this to tn for a quick look to make sure I didn't make any mistakes during the merge.
Flags: needinfo?(mstange)
Attachment #8614187 - Flags: review?(tnikkel)
Attachment #8614187 - Flags: review?(tnikkel) → review+
Attached patch merged to b2g37 (obsolete) — Splinter Review
The previous patch didn't build. Hopefully this one will. https://treeherder.mozilla.org/#/jobs?repo=try&revision=f03e44088204
Attachment #8614187 - Attachment is obsolete: true
This bug has been verified as pass on latest Nightly build of Flame v2.2 and Nexus 5 v2.2 by the STR in Comment 0. Actual results: Settings page displays normally in Usage app after user views website in browser. See attachment: verified_v2.2.mp4 Reproduce rate: 0/15 Device: Flame v2.2 build(Pass) Build ID 20150607002503 Gaia Revision 8fc797527a3eca7665bc1d1828848f2fb77ca99f Gaia Date 2015-06-04 07:46:11 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/d213237e11e9 Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150607.035848 Firmware Date Sun Jun 7 03:58:59 EDT 2015 Bootloader L1TC000118D0 Device: Nexus 5 v2.2 build(Pass) Build ID 20150607002503 Gaia Revision 8fc797527a3eca7665bc1d1828848f2fb77ca99f Gaia Date 2015-06-04 07:46:11 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/d213237e11e9 Gecko Version 37.0 Device Name hammerhead Firmware(Release) 5.1 Firmware(Incremental) eng.cltbld.20150607.035410 Firmware Date Sun Jun 7 03:54:26 EDT 2015 Bootloader HHZ12f
Attached video verified_v2.2.mp4
Leaving "verifyme" for "firefox40" verification
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: