969609 - [B2G][Email]Opening an email notification then pressing back in the email app leads to a black screen.

Status: VERIFIED FIXED

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

Description

[Andrew Stole [:astole]]

If the side menu is open in the email app and then the user presses the home button and receives an email notification, when the user selects the email notification and presses back in the email app, a blank screen appears.

Repro Steps:
1) Updated Buri BuildID: 20140207040203
2) Open the email app and log into an account
3) Set the Notifications for new messages to anything except Manually
4) Open the side menu then press the home button
5) Using a computer, send an email to the email address used in Step 2
6) Once the notification is received, select the notifications
7) After the email opens, tap the back button

Actual:
User is brought to a blank, black screen.

Expected:
User is brought back to the inbox.

Environmental Variables:
Device: Buri v1.4 M/C Mozilla RIL
BuildID: 20140207040203
Gaia: 3fc26ae786e3869a7ef1e23afc9807ac1b4741f2
Gecko: d05c721ea1b0
Version: 30.0a1
Firmware Version: V1.2-device.cfg

Repro frequency: 100%
See attached: Video

Comment 1

[Andrew Stole [:astole]]

This issue also occurs on 1.3.

Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20140207004002
Gaia: 1527d1e450364e383eeb95ff898dca2042e2b4b5
Gecko: 0a6d83aabb02
Version: 28.0
Firmware Version: V1.2-device.cfg

This issue also occurs on 1.2 except there is a blank white screen instead of blank black screen.

V1.2
Environmental Variables:
Device: Buri v1.2 Mozilla RIL
BuildID: 20140207004002
Gaia: 539a25e1887b902b8b25038c547048e691bd97f6
Gecko: 1592ce49929c
Version: 26.0
Firmware Version: V1.2-device.cfg

Comment 2

[James Burke [:jrburke]]

Attachment: GitHub pull request

This was caused because our notification entry point, and our activity entry point, were assuming that the message list card was the likely start card, if any, in the stack. However, it is possible that the user could be viewing the folder list, or even more problematic, the settings cards, that are stacked on top of the other cards.

Just inserting a card for the notification or activity at the end of that card stack results in an unexpected flow change. In particular, the card inserted may have a "back" action that is not actually back to what was shown before the card insertion, but back in a set application flow.

So this change removes all cards when coming in from an activity or notification entry point so the stack is fresh. However, if the current card is the message_list card, it is kept, as we know it is a good start point for adding cards from an activity/notification flow.

As far as removing cards and possibly losing data, the main concern would be compose. However, compose already saves a draft on a visibility change, which is the likely in order to get to the point of clicking on the notification or starting a new activity.

Not including a test since this affects 1.3, so has a good chance to be uplifted, and that branch does not have the updated test changes that allow the tests to pass well that are in master.

Comment 3

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

Comment on attachment 8372724 [details] [review]
GitHub pull request

This approach seems sane to me.  I think we want getCurrentCardType to:
- the card mode, because of that traitorous "search" mode
- consider the deferred impact of Cards._pendingPush.  This is for general sanity and because although message_list gets bundled in, "compose" does not, so we could already have a compose in-flight, etc.

The hand-waving about drafts is unfortunately too hand-wavey.  When I pull down the notification tray on b2g-desktop, I do not get a visibilitychange.  I do get one when the rocketbar task switcher thing shows up, but that's not how one gets to notifications.  Since drafts are basically inescapable at this point, I think it's sufficient for us to just differentiate an expected 'die' from an unexpected 'die'.  We don't actually track dirty state, so this would mainly just mean avoiding being dumb and double-saving when an onBack() triggered save is followed by a self-removal of the card.

NB: This is probably one of the better arguments for the Haida-controls-all infrastructure.  Then it's just a systems front-end problem! ;)

Comment 5

[Warren WU]

I think it is a blocking,please solve in 1.3.

Comment 6

[Preeti Raghunath(:Preeti)]

Is this a cert blocker? We'd like to move to backlog and fix it in 1.4, if possible.

Comment 7

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

We should probably check to see if this happens with other drawers such as in browser, and calendar.

Comment 8

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

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #7)
> We should probably check to see if this happens with other drawers such as
> in browser, and calendar.

There is no implementation commonality between these apps and e-mail.  The bug is very specific to email.

Comment 9

[Preeti Raghunath(:Preeti)]

We do think this is not a blocker in 1.3 because it is a bit tricky to
>repo.
>But a Must for 1.4.
>Have a nice day.
>Beatriz.

Comment 10

[Jason Smith [:jsmith]]

In triage product concluded this is a blocker for 1.3, but TEF has a different opinion here. Let's discuss this again.

Comment 11

[Preeti Raghunath(:Preeti)]

Adding Peter to be in the loop here. Given where we are with 1.3 would it be ok to move it to 1.4.

Comment 12

[Jason Smith [:jsmith]]

(In reply to Preeti Raghunath(:Preeti) from comment #11)
> Adding Peter to be in the loop here. Given where we are with 1.3 would it be
> ok to move it to 1.4.

I think we should be holding off to discuss this in triage again. The discussion in today's triage came to a very different conclusion than yesterday's triage, which is why bbajaj moved that to 1.3+.

Comment 13

[Peter Dolanjski [:pdol]]

Could someone confirm what happens when the user hits this situation and then tries to go to the homescreen?  Does the app close, but go back to the black screen when reopened?

The reason I ask is because if this is the case, the user will perceive the device as broken and is likely to call support or go back to the store.

Comment 14

[Jason Smith [:jsmith]]

(In reply to Peter Dolanjski [:pdol] from comment #13)
> Could someone confirm what happens when the user hits this situation and
> then tries to go to the homescreen?  Does the app close, but go back to the
> black screen when reopened?

My theory is that hitting the home button would take you back to the homescreen. If I went back to the email app while it's still running in the background, then I'd get the black screen again.

I'll add qawanted to check this though.

Comment 15

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

(In reply to Jason Smith [:jsmith] from comment #14)
> (In reply to Peter Dolanjski [:pdol] from comment #13)
> > Could someone confirm what happens when the user hits this situation and
> > then tries to go to the homescreen?  Does the app close, but go back to the
> > black screen when reopened?
> 
> My theory is that hitting the home button would take you back to the
> homescreen. If I went back to the email app while it's still running in the
> background, then I'd get the black screen again.

Correct.  Switching away from the e-mail app and back to the e-mail app via the app icon (or task switcher) never changes anything unless the OOM killer killed the e-mail app in the interim.  Re-entering the app via another notification or compose activity can change things, but generally things will still be broken.

Comment 16

[Peter Dolanjski [:pdol]]

(In reply to Andrew Sutherland (:asuth) from comment #15)
> Correct.  Switching away from the e-mail app and back to the e-mail app via
> the app icon (or task switcher) never changes anything unless the OOM killer
> killed the e-mail app in the interim.  Re-entering the app via another
> notification or compose activity can change things, but generally things
> will still be broken.

Thanks Andrew.  Given that, I think we need to block on this.  Many users will not know how to kill the app in Task Manager and will likely resort to support calls and store visits to fix their "broken" email.

Comment 17

[Jason Smith [:jsmith]]

Bumping up to blocking+ per comment 16

Comment 18

[James Burke [:jrburke]]

Comment on attachment 8372724 [details] [review]
GitHub pull request

:asuth, I did the following changes in the pull request based on review feedback:

* mail_common: getCurrentCardType now grabs the mode too, in the array format used by the query functions for Cards. Since the mode was on a JS object, not in the DOM, then I switched getting the type from `card.cardDef.name`.

* mail_app: Since getCurrentCardType returns an array ID, a helper, isCurrentCardMessageList, to check if it is the kind of message list card it cares about.

* compose: The compose card tracks if it was closed by itself, and if not, and a save was needed for a draft, then a save is done. _saveDraft was changed to accept a callback, and the die work only kills this.composer once the callback is triggered. Plus, the save prompt from onBack is closed out in the case that the user clicks on a notification while that save prompt is currently being shown.

I kept the review changes separate, it can be viewed here if you just want to diff that with previous review state:

https://github.com/jrburke/gaia/commit/5ac9ef409e8577d236d6b64cad311bad221879b9

If/when r+ happens, I would flatten/rebase to just one commit.

Comment 19

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

Comment on attachment 8372724 [details] [review]
GitHub pull request

r=asuth, with two changes:

- You don't need to wait for the draft saving to complete before calling die().  saveDraft basically snapshots the draft state and it is saved as a durable offline operation.  Since draft saving also doesn't need wi-fi access*, please just flatten out finishDie.  You can leave the callback pass-through, that might be handy for automated tests anyways.

- Handle this occurring during a send.  This starts to get into a very complicated scenario, and I think it is reasonable for us to simplify this by relying on currently valid assumptions which will cease to matter when we land background sending in v1.5.

  Assumptions:
  - If we are dying to show a notification, then we must be user interactive and so it's okay for us to release our wake-lock.  You could make the argument we should continue to hold the wake-lock until the send process returns.  However, a thing that helps me sleep at night about us not leaking wake-locks is that if you see that sending screen we have the wake-lock.  If you want to get rid of that sending screen because we've hung, then you have to kill the app and that will also kill our wake-lock too.
  - We never window.close() ourselves once the UI has been shown.

  Realities:
  - The sending process doesn't actually need us to sit there looking at the screen, it will survive.  We only made the UI be blocking because of all of the UX edge cases related to failure.
  - Because you are calling _saveDraft('automatic') we will skip the saveDraft if sending is in process.  This is awesome because it also means that if the send process successfully completes then the back-end will delete the draft and a copy of the message will end up in the sent folder.  If the send process fails, the draft stays in the drafts folder.  So if the user starts wondering what ever happened to their message, they will find it.  The regrettably edge case is that the draft will continue to exist in the drafts folder while the send process is ongoing, but this seems like a very slim danger window which will entirely go away in v1.5.

  The fix (simple):
  - In the finishCompositionSendMessage callback, early return if (!this.composer).  There's an argument to be made for that horrible sent mail sound still being played, but we definitely don't want the window.alert on failure.
  
  Side effects:
  - We will continue to "leak" the activity object and never call postResult/postError.  This is probably bad activity etiquette, but we are a windowed activity so it's not absurd since we no longer want to return to whatever app triggered us.  At this point the user has explicitly chosen they want to be 'in' the e-mail app.  Admittedly there may be some amusing fallout from this since there's already a bug filed in the e-mail app where it appears the system app gets confused because of some apparent bugs/limitations in its activity tracking, but that's the window manager's bug.  (And that might be fixed now or in the near future by the cleanup/refactoring going on there.)

Comment 20

[James Burke [:jrburke]]

Merged in master:
https://github.com/mozilla-b2g/gaia/commit/56f8ff83f112b706270150b70b753a1034625a18

from pull request:
https://github.com/mozilla-b2g/gaia/pull/16099

Comment 21

[James Burke [:jrburke]]

Comment on attachment 8372724 [details] [review]
GitHub pull request

Asking for 1.3 approval since user gets stuck in a bad state, unable to recover without killing the email app.

[Bug caused by] (feature/regressing bug #):
Bug 892519 -- the notification feature added to email in v1.2.

[User impact] if declined:
If user is viewing any other card except the message list or the message reader, the user will get stuck in a bad state where card navigation will not work. This is not fixed unless the user manually kills the email app and relaunches it.

[Testing completed]:
Dev tested on device using a notification click in a few scenarios:
* folder list shown
* settings shown
* normal message list shown
* compose: no draft to save
* compose draft to save
* compose back, showing prompt to save
* compose during a send

The compose tests were confirmed to correctly save the user's draft state before the cards were all removed to show the notification's email message.

[Risk to taking this patch] (and alternatives if risky):
Low. The changes in behavior:

* existing cards are removed when coming through the notification and activity entry points. However, those entry points are about adding a new card, so there is still UI to show. The email app has always had to support the cases where the startup only had those notification/activity cards, so no new hazards with just having those startup cards in the card stack.

* the compose card now tries to autosave when the card dies. An autosave pathway already existed for visibility change events, and if the autosave fails, it is async, and does not affect main UI display or navigation. No visible user impact.

[String changes made]:
none

Comment 22

[Warren WU]

I use this patch to test, this issue is resolved, but it will cause bug 984203.

Comment 23

[Warren WU]

I think it is need to add to determine whether there is account in mail_app.js 384 line of the patch.

Comment 24

[Jason Smith [:jsmith]]

Sounds like TCL verified the patch here, but there's a fallout seen in bug 984203.

Comment 25

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #24)
> Sounds like TCL verified the patch here, but there's a fallout seen in bug
> 984203.

bug 985093 might be another potential fallout from this patch as well.

Comment 26

[Jason Smith [:jsmith]]

Comment on attachment 8372724 [details] [review]
GitHub pull request

a- for the potential regressions caused by this patch. Let's diagnose what happened with each of the fallouts here and propose a safer fix here.

Comment 27

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

(In reply to Jason Smith [:jsmith] from comment #25)
> bug 985093 might be another potential fallout from this patch as well.

Causality seems to be that a previous problem where we failed badly and were still showing the (wrong) UI now becomes a case where we fail badly but now are showing no UI.  We should fix that and uplift that prior to this one.  This bug is still correct on that front.  Investigating the other bug now.

Comment 28

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

(In reply to [e-mail] from comment #23)
> I think it is need to add to determine whether there is account in
> mail_app.js 384 line of the patch.

I did look at this earlier today and while such a special-cased check at 384 could allow us to avoid destroying existing state just to re-create it, the code complexity does not seem justified.

(In reply to [e-mail] from comment #22)
> I use this patch to test, this issue is resolved, but it will cause bug
> 984203.

Also, as noted on that bug, we're having trouble reproducing the problem.  The family of scenarios in which this bug would matter require that the e-mail app already be running.  Given the whole "the email app is not yet configured" situation and our apparent reliability in closing ourself when the user hits cancel, that seems like a pretty QA exploratory testing type of situation that is low enough probability that it should be left as acceptable.

Comment 29

[Jason Smith [:jsmith]]

(In reply to Andrew Sutherland (:asuth) from comment #27)
> (In reply to Jason Smith [:jsmith] from comment #25)
> > bug 985093 might be another potential fallout from this patch as well.
> 
> Causality seems to be that a previous problem where we failed badly and were
> still showing the (wrong) UI now becomes a case where we fail badly but now
> are showing no UI.  We should fix that and uplift that prior to this one. 
> This bug is still correct on that front.  Investigating the other bug now.

Okay. I put 1.3+ on that bug. We'll want get approval on that bug first, land it, and then ask for approval on this bug again.

Comment 30

[Brogan Zumwalt [Inactive]]

Issue still repros for me in todays 1.3 following STR in comment 0. Another issue occurs following similar repro steps:

If user opens email settings through side menu, presses home button, then receives a new email notification, opening the email by pressing notification and then going back to inbox leaves user stuck with the sidebar open. No user inputs within email app function until app is closed and reopened.

Repro Steps:
1) Updated Buri to BuildID: 20140324004001
2) Open the email app and log into an account
3) Set the Notifications for new messages to anything except Manually
4) Open the side menu enter email settings, then press the home button
5) Using a computer, send an email to the email address used in Step 2
6) Once the notification is received, select the notifications
7) After the email opens, tap the back button

Actual:
User is brought to a inbox screen with side menu open but no user inputs are functioning.

Expected:
User is brought back to the inbox.

Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20140324004001
Gaia: f7742fb4929cc57c9f72955ce5cebb8279745ac0
Gecko: e42b778a010f
Version: 28.0
Firmware Version: v1.2-device.cfg


This seems very similar to the existing bug described here, should a new bug be filed?

Comment 31

[Jason Smith [:jsmith]]

With the regressions known here + the above comment, I'm questioning whether we should backout & try solving this with a different patch, as there's some clear problems with the current implementation.

James - What do you think?

Comment 32

[Jason Smith [:jsmith]]

Actually disregard - Andrew clarified the fact that I missed reading that comment 30 that says it's happening on 1.3. That's true because we haven't uplifted this to 1.3 yet.

Comment 33

[Ryan VanderMeulen [:RyanVM]]

Please request approval-gaia-v1.3 on this patch if it's ready for uplift to v1.3.

Comment 34

[James Burke [:jrburke]]

I believe the complicating factors is that by fixing this bug, it uncovers weaknesses in other areas. And while those weaknesses existed before, having the behavior in the bug meant there was a chance they were not as obvious of a failure before this change.

So if this bug goes to 1.3, then bug 985093 and bug 985598 would need to be uplifted too. It is my understanding that we need to wait until bug 985598 is fixed and is considered 1.3 worthy before asking for this to be uplifted.

Alternatively, bug 985598 could be considered OK to live with in 1.3, then we could proceed with uplifting this bug and bug 985093 to 1.3. I will ask on bug 985093 on if it should be considered for uplift for 1.3, then come back to this bug after that resolution is known.

As for alternatives for this bug that would avoid the other bug uplifts, I believe it would just be a different case of wack-a-mole, where we might be able to fix one or two cases of this issue, but would likely have other entry points that would have problems. We just need to reset the card state when the newly requested action is outside the normal card flow, which is what this changeset does.

Comment 35

[Ryan VanderMeulen [:RyanVM]]

Should we call this wontfix for v1.3 then and remove the blocking status?

Comment 36

[James Burke [:jrburke]]

Comment on attachment 8372724 [details] [review]
GitHub pull request

[Approval Request Comment]

Asking for approval again, now that follow-on bugs found by introducing this changeset have been fixed: 

* bug 985598 (needs to be uplifted *after* this bug is uplifted)
* bug 985093 (already uplifted)

Reusing some info from the previous approval request, but updated slightly in light of the aforementioned bugs:

[Bug caused by] (feature/regressing bug #):

Bug 892519 -- the notification feature added to email in v1.2.

[User impact] if declined:

If user is viewing any other card except the message list or the message reader, the user will get stuck in a bad state where card navigation will not work. This is not fixed unless the user manually kills the email app and relaunches it.

If this changeset is declined, then the uplift for the changeset in bug 985598 should also be declined.

[Testing completed]:

Dev tested on device using a notification click in a few scenarios:
* folder list shown
* settings shown
* normal message list shown
* compose: no draft to save
* compose draft to save
* compose back, showing prompt to save
* compose during a send

The compose tests were confirmed to correctly save the user's draft state before the cards were all removed to show the notification's email message.

Further entry point resets via activities were dev tested as part of bug 985598.

[Risk to taking this patch] (and alternatives if risky):

Given that is spawned two follow up changesets, medium risk. Although hopefully now that further testing uncovered the other bugs, after uplift of those other bugs, the fix in total should be better than the existing behavior. 

The changes in behavior:

* existing cards are removed when coming through the notification and activity entry points. However, those entry points are about adding a new card, so there is still UI to show. The email app has always had to support the cases where the startup only had those notification/activity cards, so no new hazards with just having those startup cards in the card stack.

* the compose card now tries to autosave when the card dies. An autosave pathway already existed for visibility change events, and if the autosave fails, it is async, and does not affect main UI display or navigation. No visible user impact.

[String changes made]:
none

Comment 37

[James Burke [:jrburke]]

:RyanVM - is it better for the uplift tools if I reverse the relationship of the bugs? So to have this bug, bug 969609, block bug 985598, since this bug needs to land first?

Comment 38

[Ryan VanderMeulen [:RyanVM]]

I still do things the old-fashioned way, so comment 36 works.

Comment 39

[bhavana bajaj [:bajaj]]

(In reply to James Burke [:jrburke] from comment #36)
> Comment on attachment 8372724 [details] [review]
> GitHub pull request
> 
> [Approval Request Comment]
> 
> Asking for approval again, now that follow-on bugs found by introducing this
> changeset have been fixed: 
> 
> * bug 985598 (needs to be uplifted *after* this bug is uplifted)
> * bug 985093 (already uplifted)
> 
> Reusing some info from the previous approval request, but updated slightly
> in light of the aforementioned bugs:
> 
> [Bug caused by] (feature/regressing bug #):
> 
> Bug 892519 -- the notification feature added to email in v1.2.
> 
> [User impact] if declined:
> 
> If user is viewing any other card except the message list or the message
> reader, the user will get stuck in a bad state where card navigation will
> not work. This is not fixed unless the user manually kills the email app and
> relaunches it.
> 
> If this changeset is declined, then the uplift for the changeset in bug
> 985598 should also be declined.
> 
> [Testing completed]:
> 
> Dev tested on device using a notification click in a few scenarios:
> * folder list shown
> * settings shown
> * normal message list shown
> * compose: no draft to save
> * compose draft to save
> * compose back, showing prompt to save
> * compose during a send
> 
> The compose tests were confirmed to correctly save the user's draft state
> before the cards were all removed to show the notification's email message.
> 
> Further entry point resets via activities were dev tested as part of bug
> 985598.
> 
> [Risk to taking this patch] (and alternatives if risky):
> 
> Given that is spawned two follow up changesets, medium risk. Although
> hopefully now that further testing uncovered the other bugs, after uplift of
> those other bugs, the fix in total should be better than the existing
> behavior. 
> 
> The changes in behavior:
> 
> * existing cards are removed when coming through the notification and
> activity entry points. However, those entry points are about adding a new
> card, so there is still UI to show. The email app has always had to support
> the cases where the startup only had those notification/activity cards, so
> no new hazards with just having those startup cards in the card stack.
> 
> * the compose card now tries to autosave when the card dies. An autosave
> pathway already existed for visibility change events, and if the autosave
> fails, it is async, and does not affect main UI display or navigation. No
> visible user impact.
> 
> [String changes made]:
> none

I am flagging QA to do some exploratory testing here even the risk evaluation and the landing of follow-up patches before uplifting to 1.3

Comment 40

[Tony Chung [:tchung]]

Andrew, can you verify if this is fixed on a latest 1.3 build?   Please also do some exploratory testing around hints in comment 36.   If anything is heavily regressed, reproduce and file asap.  Thanks!

Comment 41

[Andrew Stole [:astole]]

This issue still occurs on the latest 1.3 build. The issue mentioned in comment 30 still occurs as well. Also, did some exploratory around the scenarios mentioned in comment 36 and didn't run into any regressed issues or new isses.

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140418024004
Gaia: 4aae5c8e9ac9a3d7ea7e83172dda6e11169cd677
Gecko: 0fd9f6fe8832
Version: 28.0
Firmware Version: V1.2-device.cfg

Comment 42

[Jason Smith [:jsmith]]

(In reply to Tony Chung [:tchung] from comment #40)
> Andrew, can you verify if this is fixed on a latest 1.3 build?   Please also
> do some exploratory testing around hints in comment 36.   If anything is
> heavily regressed, reproduce and file asap.  Thanks!

The patch hasn't been uplifted yet, which means we shouldn't be testing 1.3 here. We should be testing trunk.

Andrew - Can you test this on trunk?

Comment 43

[Andrew Stole [:astole]]

Tested on trunk and the original issue as well as the issue mentioned in comment 30 do not occur. Tested with the scenarios in comment 36 and did not run into any regressed issues or new issues.

2.0 Environmental Variables:
Device: Buri 2.0 MOZ
BuildID: 20140418040202
Gaia: 375d87bfef8a5d7135f139da8c17f237b990d3f5
Gecko: 7fe3ee0cf8be
Version: 31.0a1
Firmware Version: V1.2-device.cfg

Comment 44

[Ryan VanderMeulen [:RyanVM]]

This is going to need a 1.3-specific patch for uplift.

Comment 45

[William Hsu [:whsu]]

QA has provided the information.
Clear the "needinfo?". Thanks Tony and Andrew!

Comment 46

[James Burke [:jrburke]]

Merged into v1.3 branch:
https://github.com/mozilla-b2g/gaia/commit/d85cfee1df629403f22e4946d520f749c090c696

from pull request:
https://github.com/mozilla-b2g/gaia/pull/18493

Comment 47

[William Hsu [:whsu]]

Also, verified it on latest V1.3.
Thanks!

* Build infromation:
 - Gaia      caab7a78f0c04913f48a3051259663ee85625906
 - Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/f84a8ffbc552
 - BuildID   20140429024001
 - Version   28.0

* Actual Result:
 - Cannot reproduce

Comment 48

[William Hsu [:whsu]]

Attachment: WP_20140430_002.mp4

Comment 49

[Roland Kunkel [:RolandK]]

Verified for v1.3T. I am unable to reproduce this issue with the latest v1.3T Tarako build:

v1.3T Environmental Variables:
Device: Tarako v1.3T MOZ RIL
BuildID: 20140530014002
Gaia: e68858693b71d917c9c5ee7e215f7ceea04635f7
Gecko: 1945abae19ff
Version: 28.1
Firmware Version: SP6821a-Gonk-4.0-5-12

Comment 50

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

remove my ni? since this one has been fixed

Comment 51

[Paladin]

According to comment #47, change "status-b2g-v1.3" to "verified".