If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[B2G][Email][Drawer] The account selecter pull-down is displayed improperly in the Drawer



Firefox OS
3 years ago
3 years ago


(Reporter: Marty, Assigned: jrburke)


Gonk (Firefox OS)

Firefox Tracking Flags

(b2g-v1.4 affected, b2g-v2.0 affected, b2g-v2.1 affected)



(3 attachments)



3 years ago
Created attachment 8467318 [details]

If the user configures more than one email account, then closes the email app, the account selector drop down in the Drawer will be displayed improperly after reopening the email app.

Once the user accesses the drop down to change accounts, it will display properly until the user adds another email account.

Repro Steps:
1) Update a Flame to 20140804040204
2) Enter the Email app and configure two email accounts.
3) Use the task manager to close the Email app
4) Re-enter the Email app and open the Drawer to view the account selector pull-down

The account selector pull-down is not displayed properly.

The account selector pull-down is displayed properly.

Environmental Variables:
Device: Flame Master
Build ID: 20140804040204
Gaia: 5fd14b8bc428f87f9b5cf9cc49f9a4f362a970fb
Gecko: e6614d8d85f9
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Keywords: Email, Drawer, Multiple Accounts, Drop-Down, List

Repro frequency: 100%
See attached: screenshot, logcat

Comment 1

3 years ago
Created attachment 8467320 [details]

This issue does NOT occur on Flame 2.0
Email selector drop down displays properly.

Environmental Variables:
Device: Flame 2.0
Build ID: 20140804000204
Gaia: 9e5907995c9327f14cb5d182cee5ff16b1743ed4
Gecko: 3f7db58a354c
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


3 years ago
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
If this does not occur we on 2.0 Flame then we need to add the regression keyword here. Also please specify the memory of the Flame 2.1 and 2.0 devices.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage-]
Flags: needinfo?(ktucker) → needinfo?(mshuman)
Keywords: regression

Comment 3

3 years ago
This issue occurs on Flame 2.1 at both 512MB and 319MB.  This issue does not occur on Flame 2.0 at either 512MB or 319MB.
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage?]
Flags: needinfo?(mshuman) → needinfo?(ktucker)
This issue only happens if the user setups a second email account and force closes the app. The drawer also corrects itself after the user taps on it so not nominating 2.1?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted

Comment 5

3 years ago
Created attachment 8468168 [details] [review]
GitHub pull request

This occurs if you open the drawer before the backend model is available. To reliably reproduce:

* Once you have a new version of the email app, with both accounts configured, open it once with the message_list shown, then close the app a bit after that. This primes the cookie cache.

* Launch the app again, and after the message list appears, but before the "last synced" final date appears, tap the menu icon to show the email drawer.

You will know if you did it at the right time if the drawer slides down, but there are no folders listed for a moment, just a gray area for them, then the data snaps in.

That gray area indicates the app is still waiting for the data to show up. However, to set up the correct sizing for the account hiding and showing, the DOM elements are checked for heights. 

With no account data loaded, one of the elements did not get the correct starting size. The fix (in this pull request) was to make sure that element had (invisible) content before sizing was checked.

QA: I expect this to be on 2.0 also, as that code has not changed between 2.0 and 2.1. Given it takes the right timing to reproduce, I expect we just got lucky when 2.0 was checked. 

So asking for qawanted to confirm 2.0 is affected, see the "gray folder section" hint above to see the case where this bug appears.
Assignee: nobody → jrburke
Attachment #8468168 - Flags: review?(m)


3 years ago
Keywords: qawanted
Able to repro on Flame 2.0, Flame 1.4 and Buri 2.1
Actual result:  Using the steps in comment 5, tapping the menu button at the right time will show a blank area for a second or two before the folders appear.  On 2.1 and 2.0 the accounts will also render incorrectly on the list.

Flame 2.0
BuildID: 20140806084615
Gaia: 47fa0ba8197e71cc7034943ff037642e7f35cdfe
Gecko: 4feed2803746
Platform Version: 32.0
Firmware Version: V122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 1.4
BuildID: 20140806081546
Gaia: e9dce1f60f729e228810f751417681b5ff937b6b
Gecko: d281a3bdfea6
Platform Version: 30.0
Firmware Version: V122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Buri 2.1
BuildID: 20140806090025
Gaia: 5e6ef81cb9e917657ce050f598229dfc83c58b8f
Gecko: f41a267983c1
Platform Version: 34.0a1
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Removing the regression and regressionwindow-wanted tages due to the fact that I was able to repro on 1.4.
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v1.4: --- → affected
status-b2g-v2.0: unaffected → affected
Flags: needinfo?(jmitchell)
Keywords: qawanted, regression, regressionwindow-wanted
QA Contact: ckreinbring
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Attachment #8468168 - Flags: review?(m) → review+

Comment 7

3 years ago
Merged in master:

from pull request:
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.