1086280 - [Music] the open activity closed and the player stopped after pressing home button

Status: RESOLVED INVALID

(Firefox OS Graveyard :: Gaia::Music, defect)

Description

[Safwan Rahman (:safwan)]

# Pair Firefox OS Device with another device over bluetooth
# Send a audio file to the Firefox OS deice and accept the transfer
# After transfer complete, play the file
# Press home button while playing the Audio file

Actual result:
# The player will stop playing the audio

Expected result:
# The player should not stop playing the audio file though press the home button

Comment 1

[Dominic Kuo [:dkuo]]

The "Actual result" is expected, the music open activity does not provide full functionalities, it acts like a previewer to preview audio files, such as the attachments in sms and email, or the received files from bluetooth, like your reproduce steps.

You can try the versions before v2.0(e.g v1.4), it's easy to reproduce that the music open activity will be close immediately right after you press the home button, thanks.

Comment 2

[Safwan Rahman (:safwan)]

Hi Dominic, Thanks for your comment. Can you please check bug 1075353 comment 40?
According to it, before the patch landed into master, the music app was acted like expected.
Can you please give me the gaia version of 2.0, where its acted like you said?

I think, the music app should play the song in background though its received by bluetooth or playing from SD card. Both time, the act should be same.

Comment 3

[Dominic Kuo [:dkuo]]

(In reply to Safwan Rahman from comment #2)
> Hi Dominic, Thanks for your comment. Can you please check bug 1075353
> comment 40?
> According to it, before the patch landed into master, the music app was
> acted like expected.
> Can you please give me the gaia version of 2.0, where its acted like you
> said?
> 
> I think, the music app should play the song in background though its
> received by bluetooth or playing from SD card. Both time, the act should be
> same.

As I mentioned in comment 1, the music open activity is different from the regular music app, it's for previewing only, so we won't expect they do exactly the same things.

If the user want to listen to the received audio files in the background, he/she can still launch the regular music to do it. And I believe the open activities was originally designed to work in this way(closed after pressed the home button), or on v1.4 we won't have this behaviour, probably you can try v1.4 first and see if the ux/behaviour convince you? thanks.

Comment 4

[Safwan Rahman (:safwan)]

Thanks for providing the branch status. But I think its not wise to compare anything with 1.4 because V1.4 has been sailed a long long ago and there is major UX/UI change in 2.0. So we need to check what make sense in 2.0. Can you please provide me any build ID of 2.0, where its working as you expected? The structure may be properly changed in 2.0, so I think the feature which I expected might be designed by UI/UX team in 2.0! :) SO if you can provide me any build ID of 2.0 where this feature is not having, so that time we can regard it as regression.

Thanks

Comment 5

[Safwan Rahman (:safwan)]

Can you please check the STR provided in comment 1 in the first nightly build of 2.0? Se we can be confirm that if the actual result is regression regression or feature.

The first nightly build of 2.0 would be in ~Mar 17, 2014.(1) So it will be helpful if you can check in the build of 16/17/18 march 2014

Comment 6

[Safwan Rahman (:safwan)]

sorry, Can you please check with the STR provided in comment 0. not comment 1 :)

Comment 7

[Dominic Kuo [:dkuo]]

(In reply to Safwan Rahman from comment #4)
> Thanks for providing the branch status. But I think its not wise to compare
> anything with 1.4 because V1.4 has been sailed a long long ago and there is
> major UX/UI change in 2.0. So we need to check what make sense in 2.0. Can
> you please provide me any build ID of 2.0, where its working as you
> expected? The structure may be properly changed in 2.0, so I think the
> feature which I expected might be designed by UI/UX team in 2.0! :) SO if
> you can provide me any build ID of 2.0 where this feature is not having, so
> that time we can regard it as regression.
> 
> Thanks

I think the major change you mentioned about should be the sheet style window management, it has lots of improvements/changes from v1.4 to v2.0 and there is a spec described about it, that is a feature. These system changes might effect the app's behaviours if one app didn't make the proper adjustment to fit them, then caused issues, just like this bug, so it's definitely a regression, because the music app didn't make any changes but has an issue which caused by some other(system) patches/features.

As I know, at least I didn't get any request to ask the music open activity to be able to play songs in the background, and for devs, how we fix the regression is to recover the broken feature, not to introduce some new features/behaviours by ourself unless we get ux inputs, or if we keep doing things like this, it confuses people because no one will know what's a regression, and what's a new feature.

Back to what you concern about, I can understand that, you think it might make sense to play the received song from bluetooth in background, but open audio file from the notification tray is just one of the music open activity cases, there are three common cases which are:

1. Open an audio attachment in email app.
2. Open an audio attachment in sms app.
3. Open an audio attachment in settings(Downloads) app.

You can see there are several possibilities to trigger the music open activity, and if we keep all these open activities playing in background, in the end the user will have more than one activity windows, and he/she wouldn't know which one is the one playing in the background, not to mention if the regular music app is already launched, I guess it will looks like, email, sms, settings and music apps are all playing songs, it's confusing.

These are just my 2 cent, let's have ux people to comment on this, Jacqueline, would you please read the previous comments(maybe also bug 1075353 but it will take a while for you) and give us some inputs? thanks!

Comment 8

[Jacqueline Savory [:jsavory] UX]

Sorry for the long delay, I agree with Dominic here that when previewing a song from another application, it should not play in the background. I think that it would cause more confusion if the preview player acted like the music player. 

I do feel that the design of the preview player could be improved however, as it visually looks very similar to the music player and I can see how a user would not be able to make this distinction. The redesign of this screen should be filed as a separate bug though.

Comment 9

[Iaroslav Voitovych]

Sorry for my opinion, but this seems to be breaking the architecture. 
When an application wants to allows a user to play a music, and a music player application is present in the system, which is by default, the application just uses the system music player by sending a "web activity" to it, instead of implementing its own music player. And if the song is long enough, the user may want to lock the screen while it's being played (this is the case I deal with by now), or to use other apps while expecting the music to be played. But the playback gets stopped if it was invoked by other application. This way an application developers have to do their own fully-functional music player to avoid just this simple issue, which does not seem to be architecturally correct and developer-friendly.