User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36 Steps to reproduce: 1. go to share 2. share an image with message 3. send it. 4. options-delete message->select all->delete->delete 5. Remains in message app Actual results: Remains in message app Expected results: No way to go back to gallery app

[Blocking Requested - why for this release]: regression, I think we should block for this.

Hey Jenny, We need your advice on this issue :) What is expected result for the STR in comment 0? The easiest option would be to just leave activity (close SMS app) and return to the gallery app. We're also have another similar case, if user opens SMS app as inline activity and then sends SMS to _several_ recipients, user is redirected to the thread list panel (inbox), but after ~3 sec we're automatically leave activity and return user to the original app. I don't know about rationale behind that, but I'm sure Julien knows :) Thanks!

(In reply to Oleg Zasypkin [:azasypkin] from comment #2) > Hey Jenny, > > We need your advice on this issue :) > > What is expected result for the STR in comment 0? The easiest option would > be to just leave activity (close SMS app) and return to the gallery app. > > We're also have another similar case, if user opens SMS app as inline > activity and then sends SMS to _several_ recipients, user is redirected to > the thread list panel (inbox), but after ~3 sec we're automatically leave > activity and return user to the original app. I don't know about rationale > behind that, but I'm sure Julien knows :) Yeah, the idea is to _see_ that the messages are correctly sent (that's why we go to the thread list as we do when we're not in an activity), but we're still leaving the activity because there is nothing left to be done. I'm sure you can find the original bug if you blame the code :)

(In reply to Julien Wajsberg [:julienw] from comment #1) > [Blocking Requested - why for this release]: regression, I think we should > block for this. Actually I'm not so sure it's a regression: previously to bug 936729 (so in versions before v2.0) we could not go back to the gallery activity either. So maybe we should not block on this after all, because it's an edge case and not a regression.

Julien, so does that mean we regressed this functionality after bug 936729 landed? Do you know what caused it? Regarding the blocking question - Julien is correct that this is not a regression from 1.3, so shouldn't block. The only reason we could block on this is if the product owners decided that this new feature is so important we could not ship without it.

Dietrich: no, it's more that this was overlooked when we landed bug 936729.

(In reply to Oleg Zasypkin [:azasypkin] from comment #2) > Hey Jenny, > > We need your advice on this issue :) > > What is expected result for the STR in comment 0? The easiest option would > be to just leave activity (close SMS app) and return to the gallery app. > > We're also have another similar case, if user opens SMS app as inline > activity and then sends SMS to _several_ recipients, user is redirected to > the thread list panel (inbox), but after ~3 sec we're automatically leave > activity and return user to the original app. I don't know about rationale > behind that, but I'm sure Julien knows :) > > Thanks! Hi Oleg, In this case, it makes more sense to return to the original app that initiates the inline SMS activity. So let's close the activity. Same should happen when user sends message from contact and deletes all the messages :) Thanks!

Hi Wayne Greetings! Will you please request someone to look into this. I request you to assign this to someone. Thanks. Ankit

Ankit - This has been backlogged as commented above and will be addressed by relevant teams.

Adding this bug as mentored bug. The relevant code is in thread_ui.js. To fix this bug it's better to use a device, but it's probably possible to fix it using B2G Desktop.

Hi Julien,thanks for your comments. Since partner is requesting this, Do you think if it's feasible we could have this fix on 2.0? and do you mind providing the fix for us? Thanks very much.

Rachelle, I'm asking a blocker status here. I personally don't think it's _that_ important to need an urgent fix. If partner want it it's easy to provide by themselves. If this bug is made a blocker we can fix it quickly.

triage: not blocking bug and corner case.

Dear Julien, I think that it can be a blocking issue for us. If you share a PR for this issue, we can test it and let you know result. Please let me know your opinion. Thank you.

Dear Youngjun Kim, The issue has not been prioritized on our side, therefore we need to work on issues that have an higher priority. If you think this is a blocking issue for you, please raise the problem with your Mozilla contact.

[Blocking Requested - why for this release]: As mentioned in Comment#15, this is a IOT blocker for partner, please help to prioritize this issue, if it is too late for 2.0, at least we should nominate as 2.1 blocker and fix ASAP Thanks Vance

Comms triage does not consider it as a blocker, so we let Release management the decision to block it or not.

Flame is also reproducible.Triage to set it to 2.0+.

Will handle this.

I was surprised that the new onHeaderAction didn't have any unit test, but well, here are at least some tests that use it. This will need a branch patch for v2.0 and maybe v2.1.

master patch applies cleanly for v2.1, and v2.0 only needs a minor change, so I won't request review again on the patch for v2.0.

Tested my patches on v2.0 and master on Flame.

Comment on attachment 8493691 [details] github PR r=me, just tiny nit on GitHub. Thanks!

master: f8d810cd48db8886460bb931e220892f19c2dd23

Comment on attachment 8493691 [details] github PR [Approval Request Comment] [Bug caused by] (feature/regressing bug #): bug 936729 [User impact] if declined: user can stay stuck in an activity (but maybe the "home" button can escape the activity still) [Testing completed]: yes, unit tests and manually [Risk to taking this patch] (and alternatives if risky): low [String changes made]: none

Comment on attachment 8493691 [details] github PR Adding verifyme to get help with verification here once it lands..

v2.1: https://github.com/mozilla-b2g/gaia/commit/e37681548b1923180e54162a8169708c8fb12d3c v2.0: https://github.com/mozilla-b2g/gaia/commit/d6662ca19da9d73456f04d7b03f154d1560a7acf

Hi Julienw Precondition:- https://github.com/mozilla-b2g/gaia/pull/23901 is merged & then if i merged this bug pull request then I have one issue. Data shared from other applications are not shown as Drafts if it has only recipient & no data. I mean go to any saved contact in contact app & send a message from there, don't write anything in messgae click(x) & save as draft. It will not be saved as draft if it has only recipient. Please, Julienw any idea why this issue is happening. Same has happen with a few more already discussed with you.. Need your little time to investigate on this. Thanks a lot.

Ankit, this is not related to this bug. You should know how we work with bugzilla now, please file a separate bug! Thanks

Verified it on v2.0 It returns to the original app. * Build information: - Gaia 279c5ee3a2b4cfd1484196a409e05ef579de1b53 - Gecko https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/f5655da30c8b - BuildID 20141002160200 - Version 32.0 - ro.build.version.incremental=27 - ro.build.date=Thu Sep 4 14:59:02 CST 2014

This issue has been verified successfully on Flame2.0&2.1&2.2 Verify video:"verify_1052447.mp4". **From comment32, Flame2.0 is OK User Agent: Flame2.1: Mozilla/5.0(Mobile;rv:34.0) Gecko/34.0 Firefox/34.0 Flame2.2: Mozilla/5.0(Mobile;rv:37.0) Gecko/37.0 Firefox/37.0 Flame2.1 build: Gaia-Rev dbaf3e31c9ba9c3436e074381744f2971e15c7bf Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ebce587d2194 Build-ID 20141203001205 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141203.034907 FW-Date Wed Dec 3 03:49:18 EST 2014 Bootloader L1TC00011880 Flame2.2 bulid: Gaia-Rev 725685831f5336cf007e36d9a812aad689604695 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/2c9781c3e9b5 Build-ID 20141203040207 Version 37.0a1 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141203.072513 FW-Date Wed Dec 3 07:25:25 EST 2014 Bootloader L1TC00011880