Closed Bug 1195547 Opened 10 years ago Closed 10 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
Status: NEW → RESOLVED
Closed: 10 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: