964530 - [Email] non-folders are selectable as message move targets

Status: RESOLVED FIXED

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

Description

[Montoya Clemmons (MClemmons)]

Description: When user moves emails to the [Gmail] folder on device, navigates to another folder and returns to the inbox on device, the Loading Messages screen appears with the sync button cycling clockwise but no messages appearing after a lengthy wait

Prerequisites:
Set up IMAP+SMTP account on device within Email App under manual setup

Repro Steps: 
1) Updated Buri to BuildID: 20140127004002
2) Tap Email App to access Inbox
3) Tap button resembling three outline dots and a checkmark at bottom of device screen
4) Select one or multiple emails by checkmarking the associated blue boxes and tap the select folder to move button and choose [Gmail] as the destination folder
5) From Inbox select the drawers icon in upper left of device screen
6) Select any other folder
7) From that folder select the drawers icon in upper left of device and select Inbox

Actual: 
Loading Messages screen appears with the sync button cycling clockwise but no messages appearing after a lengthy wait (have waited in excess of 10 minutes)

Expected: 
Messages load with limited wait

Repro frequency: (100% - 15 of 15)
See attached: logcat
Other information: 
1. Connection to internet confirmed
2. The e-mail domain used/are using to create the account – gmail.com
3. If this is not a problem creating the account, the account type the e-mail client thinks it is using: IMAP+SMTP
4. Attempting to move emails to other folders (such as Drafts, Junk, or Trash) then attempting to access the Inbox does not reproduce the behavior described above in STR

Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140127004002
Gaia: 25a45a836a4a21a30f63fa7b544b42e8b781180a
Gecko: c40099a42c1f
Version: 28.0a2
Base Image: v1.2-device.cfg

Comment 1

[Montoya Clemmons (MClemmons)]

This issue reproduces on Buri 1.2. Completing the STR reported in Comment 0 shows similar actual results on Buri 1.2. Loading messages screen displays with sync icon cycling clockwise but messages never load and appear on device screen.

Environmental Variables:
Device: buri 1.2 COM
BuildID: 20140127004002
Gaia: 539a25e1887b902b8b25038c547048e691bd97f6
Gecko: d10e1f965d0c
Version: 26.0
RIL Version: 01.02.00.019.102
Firmware Version: v1.2-device.cfg

Comment 2

[Montoya Clemmons (MClemmons)]

This issue reproduces on Buri 1.1 

Completing the STR reported in Comment 0 shows similar actual results on Buri 1.1. Loading messages screen displays with sync icon cycling clockwise but messages never load to appear on device screen.

Environmental Variables:
Device: buri 1.1 COM
BuildID: 20140127041201
Gaia: c434fe9a0e823029796805e141cfa983cda2d246
Gecko: 78de4743eec5
Version: 18.0
RIL Version: 01.01.00.019.281

Comment 3

[Montoya Clemmons (MClemmons)]

Attachment: Logcat of Never ending cycling for Inbox messages

Comment 4

[James Burke [:jrburke]]

Attachment: GitHub pull request

Some background on the cause of the bug:

Cards.folderSelector() in mail_common shows a list of folders as what would be displayed in the folder_picker. However, some folder entries, like [Gmail], are not actually selectable since they are just for hierarchical display purposes, not real folders.

However, email's value_selector does not check if folder.selectable is true, and allows any item to be tapped. This leads to a bad folder getting passed to the back end, and the back end blows up.

This pull request modified value_selector to not allow clicks for non-selectable folders. It seems desirable to show the hierarchy in the value_selector, so that it matches the display in the folder_picker card, but similar to that card, those items do not trigger any actions if they are tapped.

A deeper fix could be to also have the back end recover if this sort of data is passed to the back end and not to get stuck, but some front end fix is needed regardless, to give better feedback to the user.

Comment 5

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

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

Great investigation and attention to detail in making sure the click target stuff doesn't betray us/the user.  It seems like it would be neat if there was some way for us to convey feedback about that (play a loud buzzer sound sample for example ;), but that is a thing for another day after consultation with system-wide UX/etc..  (Which is also probably the day to add the integration test.)

Comment 6

[James Burke [:jrburke]]

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

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