1125408 - [E-Mail] Adding New Account via Manual Entry and accessing SSL Unencrypted 'Learn More' will drop user to Inbox on return to E-Mail app

Status: RESOLVED DUPLICATE of bug 1128739

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

Description

[Oliver Nelson [:oliverthor]]

Attachment: logcat_20150123_1503.txt

Description:
When the user attempts to add an additional account to their e-mail app via the Settings within E-Mail, they will observe an identical UI to their first time run. If they progress through 'Manual Setup' and change SSL settings, they may select 'Unencrypted'. The user is then prompted t make a more "secure" decision, with a the option to learn more about their selected option. Navigating through this opens the Browser app, and upon returning to E-Mail, the user will be returned to their Inbox: dropped out of their manual entry setup for a new account.

PreReq:
* One account signed in already
Repro Steps:
1) Update a Flame to 20150123010227
2) Open the E-Mail app: should be present in your inbox.
3) Tap the drawers icon for more options.
4) Tap the gear icon for account settings.
5) Tap 'Add Account'.
6) Enter a name and e-mail address and progress to 'Manual Setup'.
7) Find SSL and change value to 'Unencrypted (insecure)'.
8) Observe Browser app navigation.
9) Tap Home and return to E-Mail app.

Actual:
User will open E-Mail app to their Inbox, losing their new account login progress.

Expected:
User will open E-Mail app to resume their new account login progress.

Environmental Variables:
Device: Flame 3.0
Build ID: 20150123010227
Gaia: cba2f0bf49b882e0044c3cc583de8fcf83d2ffa4
Gecko: 494632b9afed
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Repro frequency: (5/5)
See attached: 
video- http://youtu.be/jZyn6t4L-l0
logcat

Comment 1

[Oliver Nelson [:oliverthor]]

This issue DOES NOT REPRO on flame 2.2 devices:
Results: User will open E-Mail app to resume their new account login progress.

Environmental Variables:
----------------------------------
Device: Flame 2.2
Build ID: 20150123002505
Gaia: 237008137f6d72b9cad25ff4faff14ff2c40ac63
Gecko: be24dd482a83
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
----------------------------------
Results: 3/3

Comment 2

[Peter Bylenga [:PBylenga]]

[Blocking Requested - why for this release]:
Functional regression that can lead to a broken state.

Requesting a window.

Comment 3

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

This looks like the email app got OOM-reaped.  I'm assuming this was a 319M flame device.

Given that this is a fact of life for the email app, James, maybe we should be using window.open() to trigger an overlay so we get the benefit of being the FG app and don't get reaped?

Comment 4

[James Burke [:jrburke]]

I would rather work on a generic bug about restoring our state whenever we are closed. I was looking into that as part of the streamlined startup refactoring.

We have similar problems if the user taps on a hyperlink in an email, we will reset state back to the top of the message list if we get OOMed. So I would prefer to not do special measures just for this case.

While the loss of entered data is not ideal, in this particular case, I can see the case for letting it be, since they are attempting to connect to an insecure server. If we are lucky, they will have followed the hyperlink advice and set up a new more secure account anyway, and will want to start over the account creation to use the secure provider (which also likely can use the authconfig setup). :)

Removing the regression-window wanted in the effort to save someone some work. This dialog was introduced as part of bug 1046799. It is new functionality, as nonencrypted connections were not offered as an option before that change. Given the compromised situation it puts the user in, we opted to try to steer the user to a better option via that dialog.

While the changeset is not on 2.2 yet, the hope is that it will be uplifted.

Comment 5

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

Works for me.  But noting that (manual) config is an interesting/troubling situation for state restoring though, since we wouldn't want the password stored into the URL for privacy/security reasons, and we wouldn't want to let someone construct a URL for the email app's manual config to initialize the unencrypted option.  Whereas for everything else, the URL would be sufficient.  Drafts have explicit handling, leaving really only search as a place where we type something.

Comment 6

[Dylan Oliver [:doliver]]

Can we wontfix or dupe this to a more generic startup refactoring bug?

Comment 7

[James Burke [:jrburke]]

Created bug 1128739 to track the general effort, will dupe to that one.