Pick an email and hit delete. Verify it removes from the email app inbox, but it's still on the gmail server (verify by launching in desktop browser) Environment: - 10/5 daily otoro build - gaia: ca1f327d5acc198bb4be62fa51db2c039032c9ce - gecko: ddc8eeb3f9b9ee04d9f74b4f60522eb4530a4a6f Repro: 1) setup email and add an account (gmail) 2) select an email and click delete. confirm the delete 3) go back to inbox, and verify the message may be gone. However, launch the email app in a client machine, and verify its still there Expected: - delete an email means wiping it from everywhere, including server. Actual: - delete email doesnt remove from server
This works for me on Gmail on desktop, though it's a bit hard for me to test at the moment, as my desktop build has some graphical issues.
Since we break the operation into an offline component and an online component, it is quite possible that the online bit didn't get run for some reason. Either the network stack was reporting we are offline or there was some variety of connection problem that caused a failure, etc. Casey, I think we are going to need a UI affordance to display in either the account list in the folder picker or in the settings UI that an account has pending offline operations that have not yet been played against the server which would assist QA for cases like this. Naoki, until that time, in order to identify what is happening here, we will need either console.log traces (ActiveSync currently generates console.log output for operations; IMAP does not) from "adb log" or a secret debug log from https://wiki.mozilla.org/Gaia/Email/SecretDebugMode (that must be already enabled when the thing is happening; then you can use its dump command.) And this goes for pretty much any e-mail bug; if it's not a simple case of "we landed the UI of this feature without the back-end", the back-end permutations are complex because we support offline mode and we need all the logging we can get. Thanks!
Ok, thanks for the info. I'll take a look into trying to reproduce this and get some logs.
sigh. blocked by keyboard bugs for the last several work days.
It looks like if you go offline, delete something and then go online, it doesn't seem to delete; if you were continually online and deleted something then it deletes. Hitting refresh doesn't seem to fix the issue. STR: 1. launch email for the first time, setup gmail account with test account 2. select inbox 3. send email to self (if you don't have an email to delete) 4. hit home, go to settings, turn airplane mode on 5. go back to email app 6. delete email 7. turn wifi back on 8. go back to email, hit refresh button 9. check email using desktop email client or webpage. Expected: email is deleted on the server Actual: email is not deleted on the server.
Bug 799829 cleans up and improves a lot of this handling. I'll run the STR against a gmail ActiveSync account as described here on a device once the patch up for review lands. We certainly do listen for the online notification, so my best guess is that the current failure is a case where the request fails but the operation is effectively treated as if it succeeded.
It turns out the problem is that the "Network Information API" which is a W3C standard is not implemented on B2G, so we always think we are offline and never see any transitions. I've sent an email to dev-gaia to inquire how to best learn about this data.
Offline case has to be considered for email setup as well. Might need to break that out in a different bug?
Nearly a month, no updates. Andrew, what's the next step here?
(In reply to Dietrich Ayala (:dietrich) from comment #9) > Nearly a month, no updates. Andrew, what's the next step here? This was a P3, non-C1, non-smoketest/dogfooding bug, so other bugs were worked in preference. It is still being eclipsed by some P1's but should be addressed this week.
Landed gaia-email-libs-and-more patch: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/92 on gaia/master: https://github.com/mozilla-b2g/gaia/pull/6768 This makes us correctly aware of online/offline transitions as supported by B2G. The other part of the equation landed with the sync-status-display patch which is that we will resume op processing for the account when all of the problems for the account are removed. So even if navigator.onLine insists we are online, but an account is de facto offline (for IMAP), we should still do the right thing. Namely, the account will be marked that it is not enabled while we can't talk to the server, and be re-enabled and operation processing resumed once we can successfully talk to the server.
verified on Unagi build 20130102070202 deleting an email from device also deletes it from server updating email on a desktop computer in 10 -15 seconds.