1170286 - When turning on screen with music player running, there's a brief flash of music player controls, then lockscreen-with-no-music-controls, then final lockscreen rendering with controls

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Start the "Music" app.
 2. Start playing a song, & pause it.  (so you'll see controls on lock screen)
 3. Hit power button to turn off screen.
 4. Hit power button to turn screen back on, and *watch carefully*.

ACTUAL RESULTS:
When the screen turns back on, here's what happens:
 (a) The Back/Play/Next controls appear, *all alone*.
 (b) Those controls disappear, as the rest of the lockscreen renders (without those controls)
 (c) Finally, the controls show up, on top of the lockscreen.

EXPECTED RESULTS:
We shouldn't show the weird intermediate renderings described in (a) & (b) above.  It makes the screen power-on experience jarring.


I'm using an Xperia Z3, with the following version info:
  Build Identifier: 20150528210322
  Update channel: dogfood
  Git commit info: 2015-05-28 19:50:18   18f7c340

Comment 1

[Daniel Holbert [:dholbert]]

Video of bug in action: https://www.youtube.com/watch?v=CI3srdCu5eg

Comment 2

[Daniel Holbert [:dholbert]]

Since the video is pretty fast, I'll be attaching a series of screenshots taken from the video, which show the various intermediate renderings. (There are actually 2 that I didn't mention in comment 0, involving the background image appearing, first with audio controls and then without them)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: rendering 1: just the playback controls

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: rendering 2: playback controls + background image

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: rendering 3: just the background image

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: rendering 4: full lockscreen, except for playback controls

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: rendering 5: final lockscreen appearance (with playback controls)

We flash through these intermediate renderings within a second (or a fraction of a second), so it's hard to detect each one in real life; but you can definitely see that something weird is going on.

Comment 8

[Chris Lord [:cwiiis]]

What's more annoying is that during this time, those controls are active - this also happens the other way round too, when you lock the phone, the controls stay active for a short period and can get 'stuck'. I'm frequently hitting play when I lock my phone, which can be quite embarrassing...

I believe this is a regression I caused when fixing bug 1158926, but asking for a window to make sure. I think we should block on this, and assuming I caused it, I'm volunteering to fix it.

Comment 9

[Pi Wei Cheng [:piwei] (inactive)]

This issue is reproducible on Flame 2.5 and 2.2.

Device: Flame 2.5
BuildID: 20150713010204
Gaia: e4b63559eba364892867eb381c3002d6518e5d6a
Gecko: eab21ec484bb
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 42.0a1 (2.5) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Device: Flame 2.2
BuildID: 20150713002503
Gaia: 84d0c76370dcd3d25813b00de55194730884355b
Gecko: 8d59402ba85a
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

--------------

This issue does NOT reproduce on Flame 2.1. When turning screen on with music widget on lockscreen, everything is displayed in one instance. This is not a recent regression, but rather a regression from 2.1.

Device: Flame 2.1
BuildID: 20150713001203
Gaia: d13826b20b4a45e3f5cd4b25a30a737d8be7f1b9
Gecko: 92049b3c4bb5
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 34.0 (2.1) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

--------

Working on getting the window.

Comment 10

[Pi Wei Cheng [:piwei] (inactive)]

b2g-inbound regression window:

Last Working
Device: Flame
BuildID: 20150213141858
Gaia: fa244edb7b89bf5331da2ddc87875845eec8e675
Gecko: 2ae1fcb56411
Version: 38.0a1 (2.5 Master) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

First Broken
Device: Flame
BuildID: 20150213145444
Gaia: fa244edb7b89bf5331da2ddc87875845eec8e675
Gecko: 0e2e7780755b
Version: 38.0a1 (2.5 Master) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Gaia is the same so it's a Gecko issue.

Gecko pushlog:
http://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=2ae1fcb56411&tochange=0e2e7780755b

Caused by changes made in Bug 1123762.

Comment 11

[KTucker [:KTucker][Inactive 3/4/2016]]

Mason, can you take a look at this please? This might have been caused by the work done for bug 1123762.

Comment 12

[Chris Lord [:cwiiis]]

(In reply to Pi Wei Cheng [:piwei] from comment #10)
> Gecko pushlog:
> http://hg.mozilla.org/integration/b2g-inbound/
> pushloghtml?fromchange=2ae1fcb56411&tochange=0e2e7780755b
> 
> Caused by changes made in Bug 1123762.

This is unexpected... Could you try with a recent Gecko and just reverting bug 1158926? That regression window might be a red herring.

Comment 13

[Pi Wei Cheng [:piwei] (inactive)]

We don't have the ability to revert Gecko patches. We are only set up to revert Gaia patches.  I've personally seen this bug occurring since a long time ago so it's not surprising to me.

Comment 14

[Chris Lord [:cwiiis]]

(In reply to Pi Wei Cheng [:piwei] from comment #13)
> We don't have the ability to revert Gecko patches. We are only set up to
> revert Gaia patches.  I've personally seen this bug occurring since a long
> time ago so it's not surprising to me.

Bug 1158926 is a Gaia patch, I think reverting it may 'fix' this issue (but also break what it was fixing in the first place) - if it does, I imagine bug 1158926 could be worked around in a slightly different way that doesn't cause this side-effect.

Comment 15

[Chris Lord [:cwiiis]]

n?piwei for comment #14.

Comment 16

[Pi Wei Cheng [:piwei] (inactive)]

Adding QA-Wanted to address comment 14 since I'm tied to another task for now.

Comment 17

[Mason Chang [Inactive] [:mchang]]

This seems odd...

You can try disabling silk by setting these preferences to false:

"gfx.vsync.hw-vsync.enabled"
"gfx.vsync.compositor"
"gfx.vsync.refreshdriver"

I don't have a Sony device with me so I can't test. Can you please try with these preferences off?

Comment 18

[Mason Chang [Inactive] [:mchang]]

Also, I would expect that if Silk wasn't working, we'd see nothing rendered onto the screen rather than one control then another.

Comment 19

[Pi Wei Cheng [:piwei] (inactive)]

This occurs on Flame as well.

Comment 20

[Pi Wei Cheng [:piwei] (inactive)]

Reverting https://bugzilla.mozilla.org/show_bug.cgi?id=1155091#c20 (which bug 1158926 is a dupe of) shows:

When turning screen on to show lockscreen, music widget is shown with only the background band and song name, and a fraction of a second later, music controls (previous track, pause, next track buttons) show up. To me this is not an expected behavior either.

Comment 21

[Pi Wei Cheng [:piwei] (inactive)]

QA-Wanted to address comment 17.

Comment 22

[Pi Wei Cheng [:piwei] (inactive)]

Disabling those preferences on comment 17 shows what was observed on comment 20 as well. But on my last working build everything is shown at once when turning on screen. So I'm not sure what's causing the slight difference.

I would do a video of this behavior described on comment 20, but the camera just couldn't adjust fast enough from a black screen (screen off) to a bright screen. By the time it adjusts to screen on the bug has gone away already.

So I guess either reworking bug 1155091, or reworking bug 1123762 could give us better results than current behavior.

Comment 23

[Mason Chang [Inactive] [:mchang]]

I don't think bug 1123762 has anything to do with this then. It listens to hardware vsync and schedules paints. If you are getting the same behavior with the preferences off, then the bug exists somewhere else. This sounds like a gaia race condition to me then.

Comment 24

[Josh Cheng [:josh]]

[Blocking Requested - why for this release]:
Continue fixing on next release

Comment 25

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Triage: -'ing for small visual glitch, although we agree this is pretty annoying, so we should try to address it.

Comment 26

[Chris Lord [:cwiiis]]

A note, this is slightly more than a visual glitch - those buttons also remain responsive a short time after you lock the phone and before the lock-screen comes up. I regularly end up playing music as I put my locked phone in my pocket :/

Comment 27

[BMO Automation]

Firefox OS is not being worked on