Closed Bug 1245925 Opened 8 years ago Closed 8 years ago

[Aries] Adjusting the volume turns the screen black

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
47 Branch
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla47
Project Flags:
blocking-b2g 2.6?
Tracking Flags:
Tracking Status
b2g-master --- fixed

People

(Reporter: Marty, Assigned: kats)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [2.6-Daily-Testing][Spark])

Attachments

(2 files)

logcat_volume-screen.txt
332.31 KB, text/plain
Details
MozReview Request: Bug 1245925 - Don't allow expiring the displayport on root scrollframes. r?tnikkel
58 bytes, text/x-review-board-request
tnikkel
: review+
Details 
Description:
When the user adjusts the volume, the device screen turns almost completely black, only displaying the volume meter at the top of the screen. The screen stays black until the volume meter times out.

This appears to occur anywhere on the phone except at the lockscreen, where this issue doesn't seem to occur.

Repro Steps:
1) Update a Aries to 20160204110219
2) Unlock the device
3) Adjust the volume up, then wait for the displayed volume meter to time out
4) Adjust the volume down, then wait for the displayed volume meter to time out
5) Repeat steps 3 and 4 several times

Actual:
When the volume is adjusted, the device screen goes entirely black, except for the volume meter.

Expected:
The volume meter is displayed, and all other elements of the device are properly visible beneath the meter.

Environmental Variables:
Device: Aries 2.6
Build ID: 20160204110219
Gaia: 4f0e2a1a42a2d049b6fe8f4f095cdcdf0fd5465c
Gecko: f53533d9eb771f3251921949ab2c888def70f41f
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 46.0a1 (2.6)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:46.0) Gecko/46.0 Firefox/46.0

Repro frequency: 9/10
See attached: Video (URL), Logcat
QA Whiteboard: [severe]
This issue does NOT occur on the latest Flame 2.6 or yesterday's Aries 2.6 build.
The volume meter is displayed, and all other elements of the device are properly visible beneath the meter.

Environmental Variables:
Device: Aries 2.6
BuildID: 20160203105933
Gaia: 4f0e2a1a42a2d049b6fe8f4f095cdcdf0fd5465c
Gecko: f2f8fc172f4c62334e9a92bcf10e00fe877387d5
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 46.0a1 (2.6) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:46.0) Gecko/46.0 Firefox/46.0

Environmental Variables:
Device: Flame 2.6 [512MB]
BuildID: 20160204030239
Gaia: 4f0e2a1a42a2d049b6fe8f4f095cdcdf0fd5465c
Gecko: 03297f8c28a08d2b39a252c7b368524d9e69da69
Gonk: 8a066f7fa7410e32b58def35f322aa33f03db283
Version: 46.0a1 (2.6) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:46.0) Gecko/46.0 Firefox/46.0
QA Whiteboard: [severe] → [QAnalyst-Triage?][severe]
Flags: needinfo?(ktucker)
Summary: Adjusting the volume turns the screen black → [Aries] Adjusting the volume turns the screen black
This is a bad regression. Let's get a window here.
blocking-b2g: --- → 2.6?
QA Whiteboard: [QAnalyst-Triage?][severe] → [QAnalyst-Triage+][severe]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
QA Contact: jmercado
The changes for Bug 990916 seem to have caused this issue. 

Mozilla-inbound Regression Window

Last Working 
Environmental Variables:
Device: Aries 2.6
BuildID: 20160203235028
Gaia: 4f0e2a1a42a2d049b6fe8f4f095cdcdf0fd5465c
Gecko: 772dbb329a151adf98805a3b0cd5c713f5733e08
Version: 46.0a1 (2.6) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:46.0) Gecko/46.0 Firefox/46.0

First Broken 
Environmental Variables:
Device: Aries 2.6
BuildID: 20160204001357
Gaia: 4f0e2a1a42a2d049b6fe8f4f095cdcdf0fd5465c
Gecko: a13a3af27e80440029f7a2ef9d0864274f918ad3
Version: 46.0a1 (2.6) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:46.0) Gecko/46.0 Firefox/46.0

Last Working gaia / First Broken gecko - Issue DOES occur
Gaia: 4f0e2a1a42a2d049b6fe8f4f095cdcdf0fd5465c
Gecko: a13a3af27e80440029f7a2ef9d0864274f918ad3

First Broken gaia / Last Working gecko - Issue does NOT occur
Gaia: 4f0e2a1a42a2d049b6fe8f4f095cdcdf0fd5465c
Gecko: 772dbb329a151adf98805a3b0cd5c713f5733e08

Gaia Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=772dbb329a151adf98805a3b0cd5c713f5733e08&tochange=a13a3af27e80440029f7a2ef9d0864274f918ad3
Blocks: 990916
QA Whiteboard: [QAnalyst-Triage+][severe] → [QAnalyst-Triage?][severe]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
Kartikaya can you please take a look at this?
Flags: needinfo?(bugmail.mozilla)
Yeah, I'll take a look on Monday. For now I'll just disable this code on B2G (I verified locally that adjusting the apz.displayport_expiry_ms pref to 0 fixes this) since it does seem kinda bad.
Assignee: nobody → bugmail.mozilla
Flags: needinfo?(bugmail.mozilla)
Keywords: leave-open
So this seems to be happening because the displayport is getting expired on one of the <html> elements. I'm not entirely sure which one, but probably the one that ChromeProcessController sets. Skipping the displayport expiry for mIsRoot scrollframes fixes the problem, but we probably want to be a little more specific than that, I think.
Comment on attachment 8718100 [details]
MozReview Request: Bug 1245925 - Don't allow expiring the displayport on root scrollframes. r?tnikkel

https://reviewboard.mozilla.org/r/34409/#review31115

This made me realize that displayport expiration only works on displayports that have an associated scrollframe. The displayport we set on the root elements of XUL documents is probably the only one that doesn't have a scrollframe. But it seems correct to never expire that displayport as well.
Attachment #8718100 - Flags: review?(tnikkel) → review+
Component: Gaia::System::Window Mgmt → Layout
Product: Firefox OS → Core
Version: unspecified → 47 Branch
Status: NEW → RESOLVED
Closed: 8 years ago
status-b2g-master: affected → fixed
Keywords: leave-open
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
Oh, also I'm backing out the first patch I landed (which sets the pref to 0 on b2g) because it shouldn't be needed any more.

https://hg.mozilla.org/integration/mozilla-inbound/rev/fd0c245d73f6
QA Whiteboard: [QAnalyst-Triage?][severe] → [QAnalyst-Triage+][severe]
Flags: needinfo?(ktucker)
This issue is verified fixed on the latest Aries 2.6 Dogfood build.
The volume meter is displayed, and all other elements of the device are properly visible beneath the meter.

Environmental Variables:
Device: Aries 2.6
BuildID: 20160212114105
Gaia: 4f0e2a1a42a2d049b6fe8f4f095cdcdf0fd5465c
Gecko: 3eca89d56c0252b12f8c5dadade8e8e76d852258
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 46.0a1 (2.6) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:46.0) Gecko/46.0 Firefox/46.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+][severe] → [QAnalyst-Triage?][severe]
status-b2g-master: fixed → verified
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?][severe] → [QAnalyst-Triage+][severe]
Flags: needinfo?(ktucker)
Reopening this issue. This issue is occurring on the latest Aries Central build.

When the volume is adjusted, the device screen goes entirely black, except for the volume meter.

When I verified this issue on Friday, the pref change back-out had not yet landed in Central, and so the pref change was still in the tested build.

Environmental Variables:
Device: Aries 2.6
BuildID: 20160216105618
Gaia: 4f0e2a1a42a2d049b6fe8f4f095cdcdf0fd5465c
Gecko: 6ea654cad929c9bedd8a4161a182b6189fbeae6a
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 46.0a1 (2.6) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:46.0) Gecko/46.0 Firefox/46.0
Status: VERIFIED → REOPENED
QA Whiteboard: [QAnalyst-Triage+][severe] → [QAnalyst-Triage?][failed-verification][severe]
Flags: needinfo?(bugmail.mozilla)
Resolution: FIXED → ---
(In reply to Martin Shuman [:Marty] from comment #17)
> Environmental Variables:
> Device: Aries 2.6
> BuildID: 20160216105618

Do you have a link to where I can get this build? I did a local build of the latest m-c and I cannot reproduce the problem, so I'd like to try on the nightly. I don't see any Aries builds in http://archive.mozilla.org/pub/b2g/nightly/2016/02/ though.
Flags: needinfo?(bugmail.mozilla) → needinfo?(mshuman)
Kartikaya, here is the task cluster job link for that build: https://tools.taskcluster.net/task-inspector/#HWgPNTiOQgqjF4-Xub4iqQ/
Flags: needinfo?(mshuman) → needinfo?(bugmail.mozilla)
I'm still unable to reproduce on that build. Here's what I did:

- download the aries.zip
- unzip and run ./flash.sh (i.e. full-flash)
- wait for the device to boot to the FTU
- hit "next" all the way through the FTU, accepting all defaults. skip the tour at the end
- when i get to the homescreen, try volume up/down. the screen remains non-black here.
- wait a while for the screen to time out and go off
- hit power button and unlock to get back to the homescreen. try volume up/down again. again the screen remains non-black here.

do you have different STR that can reproduce the problem? I checked the build info on the device as well and everything matches what you posted in comment 17 except that the platform version is 47.01a and not 46.0a1 (which I assume is a typo in your comment, because m-c is 47 right now).
Flags: needinfo?(bugmail.mozilla) → needinfo?(mshuman)
Your STR have been reliable for us to reproduce this bug in the past, but here are a couple other things to try:

When Jayme did the window, he had good luck by holding down the volume button up and down for about 2 seconds at a time and repeating 4 - 6 times.

Additionally, I have seen it more reliably after a fresh restart of the device if I launch an app and open and leave card view/task manager before attempting the bug.

In any case, we are reliably seeing this on the reported build within less than 5 minutes of general use and testing after start up.

(You are correct about the version number. This was a typo. The build is on version 47.0a1.)
Flags: needinfo?(mshuman) → needinfo?(bugmail.mozilla)
I tried doing what you suggested but am still unable to reproduce the problem.
Flags: needinfo?(bugmail.mozilla)
Chris, you are often running latest m-c on your B2G device - if you are running a build from the last couple of days, can you repro this issue?
Flags: needinfo?(chrislord.net)
I can confirm this is still happening and I have the patch of this bug :)
Ok, I'll try some more
Flags: needinfo?(chrislord.net)
I'm still unable to reproduce this, and I have no idea why. Since a patch landed in this bug that fixed *something* I'm going to clone this bug for the outstanding issue and close this one.
Filed bug 1250924 for it.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: