1192703 - email share activity immediately goes into background

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Dietrich Ayala (:dietrich)]

User-Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

STR:

* open twitter app, open a tweet, hit the "..." icon
* choose "email tweet"

watch as the email share screen flashes quickly and then is gone. Open card view, and you can see it's there and correctly populated.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

This looks like a debounced activity problem.  In the past we had a problem where the browser would trigger two activities for the email app in rapid succession because:
1) there's only one app servicing the activity, the email app, so now modal "hey, which app should we use for this" is shown
2) the user tapped twice, and the second tap wasn't debounced by the originating app or eaten by a modal prompt showing up or the email app's start launch showing up.

I think this is explicitly happening because our debouncing logic happens in isUiMessageTypeAllowedEntry and we do this:
    if (!isUiMessageTypeAllowedEntry('activity')) {
      return req.postError('cancelled');
    }
So we're explicitly cancelling the second activity, which probably is causing the window manager to decide that it should transition back to the triggering app.

I forget if we intentionally changed to cancel the activity or if this was something that happened in the refactor only (so ni'ing :jrburke, although he'd be the one to fix this anyways :).  There are a few things that could be done here:

1) The system app or activity subsystem can debounce / inhibit multiple activity firing in rapid succession.  This is now looking like the right thing to do since this is not the first time this has impacted the email app and the failure to debounce creates complicated issues for all downstream logic and we would not expect all apps to be as diligent as the email app.

2) The email app can drop the second activity on the floor instead of explicitly cancelling it.  I feel like in the past this may have resulted in its own problems, so this is probably not a great option.

:dietrich, needinfo'ing you to clarify if you are maybe double-tapping and to either provide a logcat of your repro or to put qawanted on the bug to request QA to provide a logcat.  email does have special logging for activities and debouncing, so there will be useful stuff in there.

Comment 2

[Dietrich Ayala (:dietrich)]

Attachment: 2015-08-10-11-41-29-logs.zip

Not double-tapping.

Comment 3

[James Burke [:jrburke]]

I can reproduce with latest eng flame-kk flash with latest master gaia flashed on top. I did not see this on what I believe is latest foxfood flash on aries.

It is definitely a "double tap" protection code when I test locally and be careful not to double tap.

Since the "..." is from the mobile twitter email app, I believe it is just a `mailto:..` link trigger, the activity data received by the email app does seem to bear this out, where the actvity data.URI is a mailto: string.

Since what I believe the same twitter.com site is used in foxfood and nightly, that part does not seem to have changed, so I suspect this indicates an issue with how gaia or b2g deals with mailto links, maybe it is triggering an activity twice?

Looking at the email code, in 2.2 we used to just ignore the second tap:
https://github.com/mozilla-b2g/gaia/blob/102f1299e9eafe3760e1deb44d556b5c4f36b5af/apps/email/js/mail_app.js#L367

But now we explicitly reject. I believe the concern was that the system is likely tracking the very last activity and if we just ignore and do not explicitly cancel, then when the user completes the email action (based on the first activity), the phone will just stay in the email app and not transfer back to the app that triggered the activity, since email tracks and notifies the first activity of the completion.

If Fabrice has knowledge of the mailto/activity logic changing, that would be good to know. If not, then I will see if I can trace a change, or ask for regression range from QA.

In general though, I agree with :asuth that b2g or the system app, whoever handles activity launches, should be providing the double tap protection, since it benefits all apps to do so. If we find a regression that causes this maybe the fix can include double tap prevention.

Comment 4

[Dietrich Ayala (:dietrich)]

I'm seeing this an Aries device, on the dogfood-latest channel, not double-tapping.

Comment 5

[[:fabrice] Fabrice Desré]

James, there has been no change in the way gecko translates mailto: uri to activities in a very, very long time.

Comment 6

[James Burke [:jrburke]]

I tried triggering the mail activity from Contacts, which uses a mozActivity. That one worked correctly, no double tap blocking. It does not have the "choose activity provider" interstitial, as the mailto: one did not. Returning to the app on cancel from within the email app also worked.

When I try this simple test page with just a mailto link on it, it also has the same failure as the twitter page:
http://jrburke.com/temp/m.html

So I still suspect something with the translation of the mailto to launching the activity provider. That, or maybe the single taps in the browser are showing up as double taps.

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

Yeah, the log is only showing one of these:
08-10 11:41:24.290   317   317 I GeckoDump: XXX FIXME : Got a mozContentEvent: activity-choice

Suggesting that there's a double-delivery rather than a double-firing.

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

Simplest next step is likely to uncomment these dump() lines, rebuild, and reproduce:
https://dxr.mozilla.org/mozilla-central/source/dom/messages/SystemMessageManager.js#23
https://dxr.mozilla.org/mozilla-central/source/dom/messages/SystemMessageInternal.js#53

Comment 9

[James Burke [:jrburke]]

The Git Commit Info for my Aries device, which does not exhibit the problem is (via Device Information):
2015-08-06 5:30:02 497fe3f9
Build Identifier is 20150806110507

The master setup on Flame that does not work (downloaded eng flame-kk flash, but then manually gaia-reset using latest gaia pull: 
2015-08-10 16:01:11 9a8880a9 
Build Identifier: 20150810030209

There was an email commit in that range for the autocomplete stuff, I reverted that locally, but that did not have an effect on this bug.

Will look a bit more after lunch.

Comment 10

[James Burke [:jrburke]]

Asking for some help finding the specific regression, the working commit in comment 9 should be a good starting point, but would be good to confirm it is good on another device.

Comment 11

[Pi Wei Cheng [:piwei] (inactive)]

mozilla inbound regression window:

Last Working
Device: Flame
BuildID: 20150805151840
Gaia: 581de383687dc441a878d2c91a0167c6ec688fef
Gecko: 15512b2f6f41
Version: 42.0a1 (2.5 Master)
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

First Broken
Device: Flame
BuildID: 20150805152140
Gaia: 581de383687dc441a878d2c91a0167c6ec688fef
Gecko: c5f710ed8718
Version: 42.0a1 (2.5 Master)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Gaia is the same so it's a Gecko issue.

Gecko pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=15512b2f6f41&tochange=c5f710ed8718

Possibly caused by changes made in Bug 1180273.

Comment 12

[Andrew Sutherland [:asuth] (he/him)]

The regression report is correct; although things are somewhat complicated.  Thanks very much for the bisection!  What is happening is characterized well by this debug logging I hacked up:

!!! mailto newChannel2
JavaScript error: , line 0: uncaught exception: 2147942487
!!! mailto newChannel deferring to newChannel2
!!! mailto newChannel2
JavaScript error: , line 0: uncaught exception: 2147942487
!!! shell.js creating activity: new from mail-handler
!!! shell.js creating activity: new from mail-handler

Before the landing of bug 1180273, the second call to newChannel would do nothing.  Now it fires a duplicate activity.  I'll comment on that bug.

Comment 14

[Pi Wei Cheng [:piwei] (inactive)]

QA: Please also check bug 1196064 when verifying this bug.

Comment 16

[Pi Wei Cheng [:piwei] (inactive)]

Is this bug considered fixed since bug 1194087 is fixed? I would like to verify this bug since we have other bugs that need share activity to be working in order to reproduce.

Comment 17

[Dietrich Ayala (:dietrich)]

WFM in today's build on dogfood-latest channel on Aries device!

Comment 18

[James Burke [:jrburke]]

Yes, bug 1194087 is the root of the issue.

Comment 19

[Pi Wei Cheng [:piwei] (inactive)]

This issue and also bug 1196064 are verified fixed on Aries and Flame. However I've discovered another bug during the process, I'll be filing that one separately.

Device: Flame 2.5
BuildID: 20150826030209
Gaia: c1ae9f02f2a9cfb89bf67aeea97e467c41c3362c
Gecko: f61c3cc0eb8b7533818e7379ccc063b611015d9d
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 43.0a1 (2.5) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Device: Aries 2.5
BuildID: 20150826051728
Gaia: c1ae9f02f2a9cfb89bf67aeea97e467c41c3362c
Gecko: f61c3cc0eb8b7533818e7379ccc063b611015d9d
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 43.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Comment 20

[Pi Wei Cheng [:piwei] (inactive)]

Filed bug 1199016 for the issue observed while verifying this bug.