Closed Bug 1230682 Opened 9 years ago Closed 9 years ago

Activesync emails cannot be deleted while syncing.

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.2 unaffected, b2g-v2.5 unaffected, b2g-master affected)

RESOLVED DUPLICATE of bug 888807
Tracking Status
b2g-v2.2 --- unaffected
b2g-v2.5 --- unaffected
b2g-master --- affected

People

(Reporter: sxean, Unassigned)

References

()

Details

(Whiteboard: [2.6-Daily-Testing])

Attachments

(1 file)

When opening an email via outlook ( activesync ) account. The email shows sync is in process while on some emails ( text ) is already fully downloaded. At this point Email will not delete during this process. Repro Steps: 1) Update an Aries to 20151204122048 2) Set-up an ActiveSync email account (outlook,hotmail, etc,...) at the email app. 3) Send an email from another email account to the Activesync account on the device. 4) Open email and observe that it's still syncing. 5) Delete the email while in the sync process. Actual: After pressing the delete button icon at bottom left of email app, the activesync email will not delete, even after repeated delete attempts. Expected: Emails delete when press the delete button icon, even during sync process. Notes: A Gmail recipient does not exhibit this behaviour and can delete during a sync process. Environmental Variables: Device: Aries 2.6 Build ID: 20151204122048 Gaia: e9419046f360dd05b2717c4994990608519b93e4 Gecko: e02b17a2b5b8df7bb84f325fc08eedd2f3cab755 Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56 Version: 45.0a1 (2.6) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0 Repro frequency: (5/5) See attached: (video clip, logcat) NO REPRO per following builds: Environmental Variables: Device: Aries 2.5 BuildID: 20151203092237 Gaia: 2d54c29f429bed790b5d8284633812dc2b782518 Gecko: 241f079cd53c932561c6aa32b9b93c44cd0846d0 Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56 Version: 44.0a2 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0 Environmental Variables: Device: Flame 2.6 BuildID: 20151204030224 Gaia: e9419046f360dd05b2717c4994990608519b93e4 Gecko: e02b17a2b5b8df7bb84f325fc08eedd2f3cab755 Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a Version: 45.0a1 (2.6) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0 Environmental Variables: Device: Flame 2.5 BuildID: 20151203091655 Gaia: 2d54c29f429bed790b5d8284633812dc2b782518 Gecko: 241f079cd53c932561c6aa32b9b93c44cd0846d0 Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a Version: 44.0a2 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0 Environmental Variables: Device: Flame 2.2 BuildID: 20151203032504 Gaia: 885647d92208fb67574ced44004ab2f29d23cb45 Gecko: 4381c4b69b9c Gonk: bd9cb3af2a0354577a6903917bc826489050b40d Version: 37.0 (2.2) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Flags: needinfo?(jmercado)
QA Whiteboard: [QAnalyst-Triage?]
Whiteboard: [QAnalyst-Triage?] → [2.6-Daily-Testing]
Additionally, the issue occurs most readily when the activesync for the email app settings have been adjusted from default values. Such as: DATA "Check for new messages" at 20 seconds. "Days to sync" set to 1 week. or another combination that is not the default.
Isabel, I don't think this issue is a blocker. The emails can be deleted after the Sync has finished just fine. Can I get your opinions though?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado) → needinfo?(irios.mozilla)
Preconditions that create the results above: Have WIFI and Cell Data enabled. Set: Data: Check for new messages: Every 15 minutes. Days to Sync: All Messages. Do not set as default. Same STR's.
This is a regrettable but expected outcome of the current implementation. There are per-folder "mutexes" that are held by anything trying to mutate a folder. All message manipulations will block until whatever is holding the mutex releases it. This should really reproduce everywhere if you are fast enough and the network is slow enough, but there's no need to try. (ActiveSync sync is the most "chunky" sync protocol we have, so it's no surprise it is the easiest to reproduce on.) I'm going to dupe over to the "fix mutexes" bug, bug 888807. Note that that bug won't be directly addressed; instead, we've overhauled how transactions and such work on the conversations branch, and once the parallelization effort happens, the problem will be fixed there.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Sorry for the late reply Jamie. Did not look a blocker and after comment #5 it is all being said. Thanks
Flags: needinfo?(irios.mozilla)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: