Created attachment 8467318 [details] logcat-Email.txt Description: 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 Actual: The account selector pull-down is not displayed properly. Expected: 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
Created attachment 8467320 [details] Email_Drawer_Screenshot.png 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
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.
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.
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?
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.
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.
Merged in master: https://github.com/mozilla-b2g/gaia/commit/b05940db3c595fd507f4a41fe1cbaec091f5b39b from pull request: https://github.com/mozilla-b2g/gaia/pull/22546