Closed Bug 1221745 Opened 4 years ago Closed 2 years ago

Share a ringtone to the messages app then share this ringtone from MMS to messages app again, the app will be closed

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:2.6+, tracking-b2g:backlog, b2g-v2.5 affected, b2g-master affected)

RESOLVED WONTFIX
blocking-b2g 2.6+
tracking-b2g backlog
Tracking Status
b2g-v2.5 --- affected
b2g-master --- affected

People

(Reporter: MaxIvanov, Unassigned)

References

()

Details

(Whiteboard: [2.6-Daily-Testing][Spark] ux-tracking)

Attachments

(1 file)

Description:
The message app will be closed after sharing a ringtone from "manage tones" and sharing this rigtone the second time from MMS.

Repro Steps:
1) Update a Flame to 20151104030208
2) Open Setting - Sound - Manage tones
3) Share any ringtone to the messages app
4) Open this ringtone from the MMS and share it to the messages again

Actual:
The message app is closed 

Expected:
We expect that a new message should be created

Environmental Variables:
Device: Flame Master
Build ID: 20151104030208
Gaia: 47da49f8206788d70d834c3a63d9245d50c89103
Gecko: 6077f51254c69a1e14e1b61acba4af451bf1783e
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 45.0a1 (Master)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Repro frequency: (100 %)
See attached: (video clip, logcat)
https://youtu.be/ksDj5BWexSU
This does occur on Flame 2.5 
The message app is closed

Device: Flame 2.5 (KK)(512mb) 
Build ID: 20151029045227
Gaia: 91cac94948094cfdcd00cba5c6483e27e80cb3b0
Gecko: acb3f4ac5424181d3d4d73283668162137918cf1
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 45.0a1 (Master)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0
--------------------------------------------------------------------------

This does occur on Aries 2.5 
The message app is closed

Device: Aries 2.5
Build ID: 20151030120435
Gaia: 91cac94948094cfdcd00cba5c6483e27e80cb3b0
Gecko: c2534acb485963331d67bbc5c07f0d862ed56bf5
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 45.0a1 (Master)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0
-------------------------------------------------------------------

This does not occur on Flame 2.2 because of different flow
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Whiteboard: [2.6-Daily-Testing]
Attached file logs.txt
This user flow seems odd. Alison, can you take a look at this please?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(ashiue)
Whiteboard: [2.6-Daily-Testing] → [2.6-Daily-Testing][Spark]
This seems a regression issue because it is weird to have "save" and "share" options when listen the attached ringtone.

Hi Tiffanie,

Do we have change the user flow after 2.5? Thanks.
Flags: needinfo?(ashiue) → needinfo?(tshakespeare)
Component: Gaia::System::Window Mgmt → Gaia::SMS
Hey Alison! Yes it's very strange to have save and share options at the same time. I would actually recommend that both are removed in this instance. You are previewing the file attachment so it doesn't really make sense to have save - what are you saving? We should remove share b/c as you mention that is allowing the user to launch into another flow and we should restrict them to finish the current task.

LMK if you have more questions. Thanks!
Flags: needinfo?(tshakespeare)
[Blocking Requested - why for this release]:
regression issue
blocking-b2g: --- → 2.5?
I have some comments here. Please remember how all this works: we use activities to trigger actions between the apps. Therefore we can't just "remove save and share" in _this_ specific case without removing in a lot ot other cases.

So we need to know if we should remove the actions:

* for all "listen" activities started from SMS (ringtones or other sound)
* for all "listen" activities started from anywhere
* for all "listen" activities started from SMS in the composer

And also think broader: what happens for other attachment types ?


Also I'd like to understand if the flow changed in 2.2. Comment 1 says "This does not occur on Flame 2.2 because of different flow", what does it mean exactly ? What changed ?


If the flow hasn't really changed, this could come from the changes in bug 1190613.


Thanks Tif.
Flags: needinfo?(tshakespeare)
QA Contact: jthomas
Hey Julien! Before diving into answering your other questions, let me answer the last one first. I haven't worked on Ringtones in quite awhile. Here is the last spec I published, you can find it here:

https://mozilla.box.com/s/5emdt54oyb1xmcpw16n20hkgxbnvfrmh

Let me know if I need to address the follow up questions!
Flags: needinfo?(tshakespeare)
It seems as though some other issues appear to be blocking me from being able to find a proper window on this issue. If I go back to the build just before thereporter's bug is triggered, the share button from the ringtone mms has NO functionality other the button is pushable. I can reference the the difference between these two builds Build A: share button is pressable with no functionality followed by the next build B: Share button will close MMS and take user back to Settings. Please let me know if you like the variables regarding these two builds. With that said, I attempted to go back further to find the truly working build and the broken share button that had no functionality. Unfortunately as I went back another issue was triggered: After attempting to share a song in MMS the screen will black out entirely for about 10 seconds and then take the user to the Homescreen. The working and broken builds for these are listed below.

Last Working
Result: User does not have the option to share ringtone in song if ringtone is already attached in MMS.

Environmental Variables:
Device: Flame 2.5
BuildID: 20150828054947
Gaia: fa15462b29258fdec8329bfc367e590022dbc9e5
Gecko: 008d4d76f387b722fbee151e1c9e1501482054e5
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 43.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

The build below has a blackout issue after attempting to share Ringtone from settings.

First Broken
Environmental Variables:
Device: Flame 2.5
BuildID: 20150828091246
Gaia: 7a77326ef8b14ddef4d101efc336d7b26670ef94
Gecko: 56a6c786bdb0a3a0c89a002f28accdc90692e5c5
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 43.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Leaving Regressionwindow-wanted tag for those who may have a better shot at pin pointing the reporter's issue.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
QA Contact: jthomas
Seems like this window will be harder to narrow down than expected, possibly impossible.  Julien can I get your opinion on what John saw in comment 9.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado) → needinfo?(felash)
Comms triage: Edge case that is not a regression. Important enough to be fixed with a high-priority, though.
blocking-b2g: 2.5? → ---
Priority: -- → P1
(In reply to Tiffanie Shakespeare [:tif] UX from comment #8)
> Hey Julien! Before diving into answering your other questions, let me answer
> the last one first. I haven't worked on Ringtones in quite awhile. Here is
> the last spec I published, you can find it here:
> 
> https://mozilla.box.com/s/5emdt54oyb1xmcpw16n20hkgxbnvfrmh

It's better if it's open by default ;) We need to stop developing behind closed doors !
(not to mention I needed 5 minutes to find by box.com password :p)


Actually the spec does not handle the cases with the Messages app. And actually I think the issue is not directly related to Ringtones but to any sound we share using MMS. TBH it's not all really clear to me.

Maybe the issue is caused here because we first share from the Ringtone app, then open the Messages app, then open the Music app, then reopen the Messages app. Maybe the flow is not possible if we start from the Music app at first. But it may happen with any other app that can share a Audio sound... And maybe with other attachment types too (images for example ?). It should be reasonnably easy to do a dumb app or even web page that can attach sounds, videos and images to try this out.

> 
> Let me know if I need to address the follow up questions!

I think the last question was really a question for QA :)

Hey Max, can you explain what you mean by "This does not occur on Flame 2.2 because of different flow" in comment 1 ?
Flags: needinfo?(felash) → needinfo?(mivanov)
Keywords: qawanted
There is no share button when you listen music files from MMS message.
Flags: needinfo?(mivanov)
OK so because we didn't change anything in the SMS app for this, I think this is due to the refactoring of the Music app.

Hey Jim, I think we didn't use to have the "share" button while in an activity in OGA, can you confirm ?
Component: Gaia::SMS → Gaia::Music
Flags: needinfo?(squibblyflabbetydoo)
QAwanted addressed on comment 13. I'll see if I can find a window for this bug.
Keywords: qawanted
QA Contact: pcheng
See comment 15
Flags: needinfo?(jmercado)
Two points:

1) The share button on step 4 is NOT available in Music OGA, making this a Music NGA only bug. It may not be caused by Music, but that share feature in Music has to be there in order to complete the STR. So technically this is not a regression from 2.2.

2) Has this share feature ever worked correctly in this particular case? The answer is no. As mentioned at comment 9, the iteration of behavior goes from 'having no functionality of share button' to this bug 1221745 since Music NGA landed as default Music.

Removing window-wanted and regression on this bug.
QA Whiteboard: [QAnalyst-Triage?]
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
See Also: → 1224142
hey Jim, see bug 1224142 comment 1, it seems like Music used to support "allowSave" in the open activity in OGA, but this support got removed in the NGA version.
blocking-b2g: --- → 2.6?
blocking-b2g: 2.6? → 2.6+
Taking to investigate what exactly we forgot.
Assignee: nobody → squibblyflabbetydoo
Status: NEW → ASSIGNED
Flags: needinfo?(squibblyflabbetydoo)
Jim, any update on this one?
Whiteboard: [2.6-Daily-Testing][Spark] → [2.6-Daily-Testing][Spark] ux-tracking
Unassigning myself. I don't plan on working on this.
Assignee: squibblyflabbetydoo → nobody
Status: ASSIGNED → NEW
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.