935764 - [B2G][Email][Notifications] User not brought to List View when invoking Group Email Notification

Status: RESOLVED WONTFIX

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

Description

[Peter Bylenga [:PBylenga]]

Description:
If user opens an email to view the body and then places email app in background then the user will not to be brought to List View when invoking a new Group Email Notification.  They’ll instead be brought to the email body that was opened.

Repro Steps:
1) Updated Buri to Build ID: 20131106004004
2) Setup an email account via Email App with a non-manual sync period.
3) Open an email to view the body.
4) Navigate to Homescreen without closing Email App.
5) Send multiple emails to the email that was setup.
6) When user receives the group email notification drag down notifications.
7) Invoke Grouped Emails and Observe.

Actual:
User is returned to original Email viewing the body of that email.

Expected:
User is brought to the list view of the grouped emails.

Environmental Variables
Device: Buri v1.2 COM RIL
Build ID: 20131106004004
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/6a831fcb96f4
Gaia: 2140c987fdde1c99097018f7e93b0bbd43d2125d
Platform Version: 26.0
RIL Version: 01.01.00.019.281 
Firmware Version: US_20131015

Notes:
Repro frequency: 5/5, 100%
Issue was discovered using Gmail

Comment 1

[Jason Smith [:jsmith]]

Sounds like incorrect behavior, although it's not a blocker. A user could workaround this by finding the new email directly with the app open.

Comment 3

[Tony Chung [:tchung]]

James, is this broken functionality in the group notification feature?   if so, we should consider this a feature blocker.

Comment 5

[James Burke [:jrburke]]

Yes, looks like a bug, I can reproduce and see the why the code produces the bug. The bug is not a problem with notification grouping, just an interior email code logic error when the app is already running and has a message_list in the DOM, but not visible.

Notes on the code issue: in mail_app.js, showMessageList is called, which then ends up calling resetCards('message_list', args), which will only result in a card move if the message_list card was not already in the DOM.

So first thought is that resetCards should then navigate to the card if it exists. Need to check resetCards usage to be sure, but the comment for the function indicates that was the desired outcome.

Comment 6

[BMO Automation]

Firefox OS is not being worked on