Closed Bug 1157099 Opened 9 years ago Closed 9 years ago

[email][FFOS7715 v2.1]Set the email account and successful into the mail .Complete withdrawal from E-mail application from the background .Enter again, there will be a brief pop box create email account.

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1106888

People

(Reporter: ffos_st, Unassigned)

Details

(Whiteboard: sprd426168)

Description:
Set the email account and successful into the mail .Complete withdrawal from E-mail application from the background .Enter again, there will be a brief pop box create email account.

Device:
SPRD 7715ea

Build Identifier:
20150422114850

Steps to Reproduce:
1)Add email accounts, successfully into the mail
2)Complete withdrawal from E-mail application from the background
3)Enter again

Actual Result: 
There will be a brief pop box create email account, be misleading to the user.

Expected Result:
Should go into the mail 

Repro frequency:
5/5,100%
Please help to analysis.thanks~
Flags: needinfo?(vchen)
Flags: needinfo?(sku)
Whiteboard: sprd426168
Hi ffos_st. could you help to provide a reproduce video for this?

Thanks
Flags: needinfo?(vchen) → needinfo?(ffos_st)
Hi Vance Chen:

I provide the video, the following links:
http://pan.baidu.com/s/1bnvZwq7

Please help,thanks
Flags: needinfo?(ffos_st)
Hi ffos_st, thanks, i saw the video and have some follow up questions

1. Can you reproduce this issue in Flame as well?

2. Can you reproduce this issue by email account other than QQ?

3. I notice that you press home key to back to idle while the Email application is still loading the email. Can you still reproduce this issue if you back to idle only after all the emails have been loaded?

Finally, could you also provide logcat log for this issue as well?

Thanks for your help
Flags: needinfo?(ffos_st)
Hi Vance Chen:

I have a question want to confirm to you,the following:

I have test on 7715 and flame with 126,163 and qq account.
case1:When press home key to back to idle while the Email application is still loading the email,the pop box occur.
case2:When back to idle only after all the emails have been loaded,the pop box not occur and it works well.

I have a question if case1 the operation is correct?

Thanks for your help
Flags: needinfo?(ffos_st)
(In reply to ffos_st from comment #5)
> Hi Vance Chen:
> 
> I have a question want to confirm to you,the following:
> 
> I have test on 7715 and flame with 126,163 and qq account.
> case1:When press home key to back to idle while the Email application is
> still loading the email,the pop box occur.
> case2:When back to idle only after all the emails have been loaded,the pop
> box not occur and it works well.
> 
> I have a question if case1 the operation is correct?
> 
> Thanks for your help

Hi ffos_st-

I think operation 1 is still a valid operation for end user, we should do something to prevent the new account screen to show up again even if the messages are not yet fully loaded during the account creation

Hi Andrew, are you still working on Email? could you help to check this one? The following video might help you to better understand this issue:

https://www.youtube.com/watch?v=cKYHt91JNvw&feature=youtu.be

Thanks!

Thanks
Flags: needinfo?(bugmail)
Hi Vance Chen and Andrew:

The logcat log for this issue:

http://pan.baidu.com/s/1qWA1XQO
I cannot watch the video or see the logcat (just attaching them to this bug as attachments is preferred), but I can see how this might happen with the following steps. It is basically an interaction with the startup cache we use in email.

* Open email to New Account card (this card gets saved in the startup cache)

* Enter account details, and while the email account is getting set up, the home button is tapped.

* When going back to the home screen, maybe something else is done there and the email app gets killed due to the Out of Memory (OOM) mechanism.

* Tapping the email relaunches the email app. Since the app was killed via OOM, this is a fresh app launch.

* The startup cache is used for fresh app launches. It is still set to the New Account screen because the user did not wait until the Message List card to show (which then replaces the New Account startup cache with itself, the desired behavior).

* So the user briefly sees the New Account startup cache, but once the email backend starts up, it recognizes that there is an account configured and the cache is cleared.

This was fixed in 2.2 (and is also fixed in 3.0) in bug 1106888. It would be good to confirm the steps above are what happened (mainly when going back to home screen confirm that email app then is no longer running). If that is the case though, then I suggest duping this bug to bug 1106888.
Flags: needinfo?(bugmail)
(In reply to James Burke [:jrburke] from comment #8)
> I cannot watch the video or see the logcat (just attaching them to this bug
> as attachments is preferred), but I can see how this might happen with the
> following steps. It is basically an interaction with the startup cache we
> use in email.
> 
> * Open email to New Account card (this card gets saved in the startup cache)
> 
> * Enter account details, and while the email account is getting set up, the
> home button is tapped.
> 
> * When going back to the home screen, maybe something else is done there and
> the email app gets killed due to the Out of Memory (OOM) mechanism.
> 
> * Tapping the email relaunches the email app. Since the app was killed via
> OOM, this is a fresh app launch.
> 
> * The startup cache is used for fresh app launches. It is still set to the
> New Account screen because the user did not wait until the Message List card
> to show (which then replaces the New Account startup cache with itself, the
> desired behavior).
> 
> * So the user briefly sees the New Account startup cache, but once the email
> backend starts up, it recognizes that there is an account configured and the
> cache is cleared.
> 
> This was fixed in 2.2 (and is also fixed in 3.0) in bug 1106888. It would be
> good to confirm the steps above are what happened (mainly when going back to
> home screen confirm that email app then is no longer running). If that is
> the case though, then I suggest duping this bug to bug 1106888.

Hi James, I upload the video to youtube, you should be able to see it in here[1]. I believe what captured in the video is similiar as you describe here. The only difference here is the EMail is deliberately killed by tester, not by OOM mechanism.

Hi ffos_ft, could you try the patch at Bug#1106888 to see if it works?

Thanks

[1]
https://www.youtube.com/watch?v=cKYHt91JNvw&feature=youtu.be
Flags: needinfo?(sku)
Flags: needinfo?(jrburke)
Flags: needinfo?(ffos_st)
Thanks Vance: yes, the deliberate kill will definitely lead to the same result. I will let ffos_st confirm, but this really looks like a dupe of bug 1106888.
Flags: needinfo?(jrburke)
Hi Vance and James:

I've tried the patch of Bug1106888 and it works well. I think bug1157099 and bug1106888 is the same issue and the issue has been solved.

Thanks for your help.
Flags: needinfo?(ffos_st)
Hi ffos_st-

Great, thanks for the feedback, then I will DUP this one and close it

Thanks
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.