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
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
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)
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!
[Blocking Requested - why for this release]: regression issue
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.
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!
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?]
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.
(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)
There is no share button when you listen music files from MMS message.
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
QAwanted addressed on comment 13. I'll see if I can find a window for this bug.
QA Contact: pcheng
See comment 15
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?] → [QAnalyst-Triage+]
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.
Taking to investigate what exactly we forgot.
Assignee: nobody → squibblyflabbetydoo
Status: NEW → ASSIGNED
Jim, any update on this one?
4 years ago
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.