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

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

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)

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.

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.

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.

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.

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

(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.

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.

(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.

n?piwei for comment #14.

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

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?

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

This occurs on Flame as well.

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.

QA-Wanted to address comment 17.

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.

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.

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

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

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 :/

Firefox OS is not being worked on