Closed Bug 1195547 Opened 9 years ago Closed 9 years ago

[Music] Music widget is not present on lockscreen when first playing a song without skipping or re-selecting.

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.5+, b2g-v2.2 unaffected, b2g-master verified)

VERIFIED FIXED
FxOS-S8 (02Oct)
blocking-b2g 2.5+
Tracking Status
b2g-v2.2 --- unaffected
b2g-master --- verified

People

(Reporter: NicholasN, Assigned: etienne)

References

()

Details

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

Attachments

(3 files)

Attached file logcat_music.txt
Description:
On fresh flash or after resetting the device in settings, the user opens the music app, selects a song and it begins playing. They lock the phone and the music continues to play, but the music controls/widget are not present on the lockscreen. If the user goes back and skips the song forward or selects a different song, the control widget will be present on the lockscreen. This only appears to happen on a fresh flash/reset.


Repro Steps:
1) Update a Aries to 20150817141354
2) Open the music app.
3) Select a song and play it.
4) Tap the power button once to lock the device, and again to wake it up.


Actual:
Music control widget is not present on lockscreen.


Expected:
Music control widge is present if music is playing.


Notes:

Environmental Variables:
Device: Aries 2.5
Build ID: 20150817141354
Gaia: 60489c1ff8c5d1633fc4837d4f8019623d4e1940
Gecko: a6eeb28458fd2652e12e57334f046b7776d75bb4
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 43.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0


Repro frequency: 5/5
See attached: video clip, logcat
Issue occurs on Flame 2.5 but not on Flame 2.2.

Flame 2.5

Actual Result:
Music widget is not present on lockscreen when playing song for the first time.

Environmental Variables:
Device: Flame 2.5
BuildID: 20150817061040
Gaia: 60489c1ff8c5d1633fc4837d4f8019623d4e1940
Gecko: a6eeb28458fd2652e12e57334f046b7776d75bb4
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 43.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Flame 2.2

Actual Result:
Music widget is present on the lock screen.

Environmental Variables:
Device: Flame 2.2
BuildID: 20150817032503
Gaia: 335cd8e79c20f8d8e93a6efc9b97cc0ec17b5a46
Gecko: 82ec88fa015c
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: regression
Whiteboard: [2.5-Daily-Testing][Spark]
[Blocking Requested - why for this release]:
Noticeable functional regression

Requesting a window
blocking-b2g: --- → 2.5?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QA Contact: pcheng
b2g-inbound regression window:

Last Working
Device: Flame
BuildID: 20150604012244
Gaia: e0fbadeb78a96137f071d9be7a47ef9fe882d17f
Gecko: 64ce149fabf1
Version: 41.0a1 (2.5 Master) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

First Broken
Device: Flame
BuildID: 20150604020845
Gaia: c1ef854924f18357832ddcf98dc6c42391d5599e
Gecko: 4f7e7631e277
Version: 41.0a1 (2.5 Master) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Last Working Gaia First Broken Gecko - no repro
Gaia: e0fbadeb78a96137f071d9be7a47ef9fe882d17f
Gecko: 4f7e7631e277

Last Working Gecko First Broken Gaia - repro
Gaia: c1ef854924f18357832ddcf98dc6c42391d5599e
Gecko: 64ce149fabf1

Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/e0fbadeb78a96137f071d9be7a47ef9fe882d17f...c1ef854924f18357832ddcf98dc6c42391d5599e

Caused by changes made in Bug 1094759.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Etienne, Kevin

This issue seems to be a result of Bug 1094759 and Alive is inactive.  Can you take a look at this or pass it to someone who can?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(kevingrandon)
Flags: needinfo?(jmercado)
Flags: needinfo?(etienne)
I may be able to take a look if no one gets to it, but maybe someone more familiar with lockscreen/music would be a better choice. Let's get a blocking decision here first.
Flags: needinfo?(kevingrandon)
Whiteboard: [2.5-Daily-Testing][Spark] → [2.5-Daily-Testing][Spark][systemsfe]
8/19 triage: Blocking for regression.
blocking-b2g: 2.5? → 2.5+
Component: Gaia::Music → Gaia::System
Component: Gaia::System → Gaia::System::Lockscreen
Whiteboard: [2.5-Daily-Testing][Spark][systemsfe] → [2.5-Daily-Testing][Spark]
What's happening is that we only start the LockscreenAgent when the LockscreenWindow is created.
So, when going through FTU and following the STR the LockscreenAgent is started _after_ the music and the controls aren't shown.
Flags: needinfo?(etienne)
Assignee: nobody → etienne
Attachment #8658646 - Flags: review?(gweng)
Thanks patching. However, since it is a blocker from Alive's changing about lazy loading and the different booting sequence, I think the solution is that we pull these message handlers, which may need to know the message before the normal opening and loading things, from the window to the manager. Otherwise, we may nullify the effect of the that bug. Since to satisfy the booting order dependency by forcibly creating the window at the booting time, seems to bring the old way of loading everything at the booting time back.

Note this is not saying we move the whole agent out, but only such kinds of special requests. I think this can be distinguished by treating these messages as actually two types of different requests, and the first one is those will come at anytime even before the window get invoked, just like FMD command:

https://github.com/etiennesegonzac/gaia/blob/bug-1195547/apps/system/js/lock_screen_window_manager.js#L254

So we could listen to the 'iac-mediacomms' in the manager, and keep the state as a booting parameter to LockScreen (after it becomes an iframe we can set these params as URL hash or something like that). This solution will allow us to not change the way of current booting and loading, the time of creating the window, and separate the previously mixed improperly messages which should be changed after the new system bootstrapping. The only concern is whether we can make this change on schedule for v2.5, so I leave the NI to see if it is good to you as well.
Flags: needinfo?(etienne)
Comment on attachment 8658646 [details] [review]
[gaia] etiennesegonzac:bug-1195547 > mozilla-b2g:master

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #9)
> So we could listen to the 'iac-mediacomms' in the manager, and keep the
> state as a booting parameter to LockScreen (after it becomes an iframe we
> can set these params as URL hash or something like that). This solution will
> allow us to not change the way of current booting and loading, the time of
> creating the window, and separate the previously mixed improperly messages
> which should be changed after the new system bootstrapping. The only concern
> is whether we can make this change on schedule for v2.5, so I leave the NI
> to see if it is good to you as well.

Good points. Here's what I think is a good compromise:
we keep the booting and loading unchanged but request up to date mediacomm information at load time.

The music app already had this implemented for remotes I just added support for it through the IAC channel (and adding Jim to review this part).
Flags: needinfo?(etienne)
Attachment #8658646 - Flags: review?(squibblyflabbetydoo)
Comment on attachment 8658646 [details] [review]
[gaia] etiennesegonzac:bug-1195547 > mozilla-b2g:master

I don't see any actual problems with this, but I know next-to-nothing about how the lockscreen is currently implemented.
Attachment #8658646 - Flags: review?(squibblyflabbetydoo) → review+
Comment on attachment 8658646 [details] [review]
[gaia] etiennesegonzac:bug-1195547 > mozilla-b2g:master

From the lockscreen part, I think it's good to me if the only change is to inquire if there are any data before the widget launches. Thanks.
Attachment #8658646 - Flags: review?(gweng) → review+
Keywords: checkin-needed
https://github.com/mozilla-b2g/gaia/commit/2fc7dcdce2ee2547f42021bcb098bb0583d2e495
Status: NEW → RESOLVED
Closed: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → FxOS-S8 (02Oct)
This bug has been verified as "pass" on the latest build of Flame KK 2.5 and Aires KK 2.5 by the STR in comment 0.

Actual results: Music widget is present on lockscreen when first playing a song without skipping or re-selecting.
See attachment: verified_Aries_v2.5.3gp
Reproduce rate: 0/10


Device: Flame KK 2.5 (Pass)
Build ID               20150920150205
Gaia Revision          e67d319d0854e32e23210784eb9c4e1b8a025adb
Gaia Date              2015-09-19 07:42:05
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/ccd6b5f5e544c1d708849144943a776941bd3794
Gecko Version          43.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150920.182952
Firmware Date          Sun Sep 20 18:30:04 EDT 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Aries KK 2.5 (Pass)
Build ID               20150920050928
Gaia Revision          e67d319d0854e32e23210784eb9c4e1b8a025adb
Gaia Date              2015-09-19 07:42:05
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/ccd6b5f5e544c1d708849144943a776941bd3794
Gecko Version          43.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150920.042926
Firmware Date          Sun Sep 20 04:29:33 UTC 2015
Bootloader             s1
Status: RESOLVED → VERIFIED
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: