Closed
Bug 900371
Opened 11 years ago
Closed 11 years ago
[Buri][Clock][Music] After ignoring the alarm and music plays in the foreground, we can hear alarm and music at the same time
Categories
(Firefox OS Graveyard :: Gaia::Clock, defect, P1)
Firefox OS Graveyard
Gaia::Clock
Tracking
(tracking-b2g:backlog)
RESOLVED
DUPLICATE
of bug 996092
tracking-b2g | backlog |
People
(Reporter: sync-1, Assigned: mcav)
References
Details
(Keywords: feature, Whiteboard: [AUDIO_COMPETING] [UX_TRIAGED] [p=3])
Attachments
(1 file)
53.41 KB,
application/octet-stream
|
Details |
AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.171
Firefox os v1.1
Mozilla build ID:20130722070207
Created an attachment (id=476359)
Logcat
DEFECT DESCRIPTION:
The music progress bar still is playing when alarm comes
REPRODUCING PROCEDURES:
Precondition: plug in the standard headset
1.Launch Music app -> select a song to play
2.Launch Clock app -> set an alarm in one minute, save it
3.Alarm comes at time -> set alarm reminder to status bar -> then enter music -> the music progress bar still is playing and it has no sound -> KO
EXPECTED BEHAVIOUR:
The music should pause when alarm comes.
If designed that the music still plays, it should has sound.
ASSOCIATE SPECIFICATION:
TEST PLAN REFERENCE:
TOOLS AND PLATFORMS USED:
USER IMPACT:
Mid
REPRODUCING RATE:
5/5
For FT PR, Please list reference mobile's behavior:
Comment 3•11 years ago
|
||
The issue could be no updating status from audio channel. Clock app is not able to handle it for music app.
Component: Gaia::Clock → Gaia::Music
Comment 4•11 years ago
|
||
If the progress bar is still updating while the alarm rings, then the music should be playing but muted. This should be the current behaviour of the audio channel, the muted channel is still playing. Unless the audio channel pauses the audio element or music app should not stop updating the progress bar.
I will first reassign it to system component because this seems related to the audio competing issues.
Component: Gaia::Music → Gaia::System
Whiteboard: [AUDIO_COMPETING]
Comment 5•11 years ago
|
||
Update:
This behaviour is changed since the audio competing policy has updated. In 1.3, after the user press home button to ignore the alarm while music app is also playing in the background, then bring music app to the foreground, the sounds of alarm and music will be mixed together, that's, we can hear both the alarm and music even the alarm window is minimized in the status bar.
As described above, it seems we can change the behaviour to avoid this issue, and get better user experiences as well, like snooze/mute the alarm once the user press the home button, then alarm and music won't be able to be heard at the same time.
We will need some ux inputs if we want to fix this by changing the alarm's behaviour, cc'ing Juwei to catch her attention.
Component: Gaia::System → Gaia::Clock
Summary: [Buri][Clock][Music]The music progress bar still is playing without sound when alarm comes → [Buri][Clock][Music] After ignoring the alarm and music plays in the foreground, we can hear alarm and music at the same time
Assignee | ||
Comment 6•11 years ago
|
||
Juwei, do we want to snooze/mute the alarm when the user presses the home button?
Flags: needinfo?(jhuang)
Comment 7•11 years ago
|
||
The music should pause when the alarm go off, indeed.
However, this situation is more about what alarm will happen when tap on the home button. My suggestion would be snooze the alarm since it makes no sense that the alarm still ringing after the user does some actions. It is supposed to cancel or snooze the alarm at the moment.
So I am more prefer to snooze the alarm just in case people miss it and discard the alarm banner over the top of screen right now.
Here's the flow:
Play music in the background -->Alarm goes off, pause the music --> Tap on home button --> Snooze the alarm, play music.
Flags: needinfo?(jhuang)
Comment 8•11 years ago
|
||
[UX_TRIAGED]
As Juwei commented in comment 7, we will go for the approach.
I don't know the clock code, but I guess the possible solution could be the alarm listen to the |resize| event, once the window is being minimized, then alarm should know the home button is pressed and triggered the window to be resized, then snooze the alarm, it sounds like we can have this in 1.4.
Marcus, I am nominating this bug to 1.4 because in the offline audio competing meeting, ux team thought this is a simple fix that give better ux, and won't give too many effort for dev, but if you think it's not going to happen in 1.4, please let us know and let's have this in the later version, thanks.
blocking-b2g: --- → 1.4?
Whiteboard: [AUDIO_COMPETING] → [AUDIO_COMPETING] [UX_TRIAGED]
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → m
Status: NEW → ASSIGNED
Target Milestone: --- → 1.4 S2 (28feb)
Assignee | ||
Updated•11 years ago
|
Whiteboard: [AUDIO_COMPETING] [UX_TRIAGED] → [AUDIO_COMPETING] [UX_TRIAGED] [p=3]
Assignee | ||
Updated•11 years ago
|
Target Milestone: 1.4 S2 (28feb) → ---
Assignee | ||
Updated•11 years ago
|
Assignee | ||
Comment 10•11 years ago
|
||
Fixed in bug 996092 per Juwei's recommendation in Comment 7.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Updated•10 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
You need to log in
before you can comment on or make changes to this bug.
Description
•