Closed Bug 1065167 Opened 11 years ago Closed 11 years ago

[email] The contents of the outbox won't show until any active sending process completes due to held mutex by sending process

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.1 verified, b2g-v2.2 verified)

VERIFIED FIXED
2.1 S5 (26sep)
Tracking Status
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: smiko, Assigned: mcav)

References

()

Details

(Whiteboard: [2.1-flame-test-run-2])

Attachments

(3 files)

Attached file outbox2.txt
Description: Emails are not displayed in the outbox while in the process of being sent. According to user story: Bug 949498, emails should be placed in the outbox until the transmission completes. Repro Steps: 1: Update a Flame to 20140908000204 2: Open Email and create a new email 3: Attach a video around 5 seconds in length and hit Send 4: While the email is sending, switch to the outbox Actual: The email does not appear, even when refreshing Expected: The email is displayed in the outbox until the transmission completes. Flame 2.1(319mb) Environmental Variables: Device: Flame 2.1 (319mb) Build ID: 20140908000204 Gaia: a8e4d26555e5713ec6c72270cfd0cfabc096a0d3 Gecko: 746f24f9d21d Version: 34.0a2 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Notes: Emails DO appear in the outbox until sent when composing the email while in the outbox folder Repro frequency: 100% See attached: logcat Video clip:http://youtu.be/Mobt2zIaV8A
This issue DOES occur on Flame 2.2(319mb), Open C 2.2, Flame 2.1(512mb), Open C 2.1, Actual result: Email is not shown in outbox Flame 2.2 (319mb) Environmental Variables: Device: Flame Master (319mb) Build ID: 20140908040204 Gaia: c71fd5d8c9c7cb021c97e5e9fbb29f92b50a084d Gecko: 892768985915 Version: 35.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Open C 2.2 Environmental Variables: Device: Open_C Master Build ID: 20140908040204 Gaia: c71fd5d8c9c7cb021c97e5e9fbb29f92b50a084d Gecko: 892768985915 Version: 35.0a1 (Master) Firmware Version: P821A10V1.0.0B06_LOG_DL User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Flame 2.1 (512mb) Environmental Variables: Device: Flame 2.1(512mb) Build ID: 20140908000204 Gaia: a8e4d26555e5713ec6c72270cfd0cfabc096a0d3 Gecko: 746f24f9d21d Version: 34.0a2 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Open C 2.1 Environmental Variables: Device: Open_C 2.1 Build ID: 20140908000204 Gaia: a8e4d26555e5713ec6c72270cfd0cfabc096a0d3 Gecko: 746f24f9d21d Version: 34.0a2 (Master) Firmware Version: P821A10V1.0.0B06_LOG_DL User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 This issue does NOT occur on Flame 2.0(319mb), or Open C 2.0 as the outbox feature does not exist Flame 2.0 (319mb) Environmental Variables: Device: Flame 2.0 (319mb) Build ID: 20140908000202 Gaia: f02a8e4ef0fabeb28593fa660a0a4ca8a5fe67e5 Gecko: 8e46e547f4ad Version: 32.0 (2.0) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Open_C 2.0 Environmental Variables: Device: Open_C 2.0 Build ID: 20140908000202 Gaia: f02a8e4ef0fabeb28593fa660a0a4ca8a5fe67e5 Gecko: 8e46e547f4ad Version: 32.0 (2.0) Firmware Version: P821A10V1.0.0B06_LOG_DL User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Whiteboard: [2.1-flame-test-run-2]
Edward, can you look at this and weigh in on whether or not this should block 2.1?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(edchen)
It's a mutex issue. We could probably mitigate the outbox and local drafts case separately since they don't actually have a sync process and therefore they don't actually need to hold a mutex when syncing. (All of their mutating operations run via job-ops.) Specifically, we could probably make FolderStorage.sliceOpenMostRecent and FolderStorage.refreshSlice explicitly bypass runMutexed when they are isLocalOnly() (providing a no-op completion callback) as our stop-gap. :mcav, does that sound sane to you?
Flags: needinfo?(m)
Yeah, that's doable.
Assignee: nobody → m
Status: NEW → ASSIGNED
Flags: needinfo?(m)
Target Milestone: --- → 2.1 S5 (26sep)
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage+] → [COM=Gaia::E-Mail][QAnalyst-Triage+]
Flags: needinfo?(edchen)
Summary: [email] Emails in the sending process do not appear in outbox → [email] The contents of the outbox won't show until any active sending process completes due to held mutex by sending process
QA Whiteboard: [COM=Gaia::E-Mail][QAnalyst-Triage+] → [COM=Gaia::E-Mail][QAnalyst-Triage+][lead-review+]
Comment on attachment 8487370 [details] [review] Link to Github pull-request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/338 r=asuth, and the patch speaks for itself fantastically with comments. In the event I do not say it enough, I am so happy that you are hacking on the email back-end. I feel like I should get one of those Staples "easy" buttons and hack it to be you saying "It's handled." Now I just need to do the Sneakers (movie) thing where I get some random person to trick you into saying "It's handled" without you being the wiser...
Attachment #8487370 - Flags: review?(bugmail) → review+
QA Contact: edchen
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment on attachment 8487370 [details] [review] Link to Github pull-request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/338 [Approval Request Comment] Requesting uplift to 2.1; low-risk fix that allows the outbox to be displayed properly while other operations are going on in the Email app. [Bug caused by] (feature/regressing bug #): outbox feature, in v2.1 [User impact] if declined: see bug title [Testing completed]: yes, automated/manual [Risk to taking this patch] (and alternatives if risky): low [String changes made]: none
Attachment #8487370 - Flags: approval-gaia-v2.1?
triage: not blocking, does not meet the bar of "major issue" in new feature. will wait for approval decision
blocking-b2g: 2.1? → ---
Attachment #8487370 - Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
[Environment] Gaia-Rev b3f9b97d16a1ab55f80239d63c1a85c3da3d39ad Gecko-Rev https://hg.mozilla.org/releases/mozilla-aurora/rev/2c6e3261c47b Build ID 20140921160204 Version 34.0a2 Device Name flame FW-Release 4.3 FW-Incremental 110 FW-Date Fri Jun 27 15:57:58 CST 2014 Bootloader L1TC00011230 [Result] PASS
Status: RESOLVED → VERIFIED
Attached video verify.3gp
This issue has been successfully verified on Flame 2.1, 2.2 See attachment:verify.3gp Reproducing rate: 0/5 Flame 2.1 new build: Gaia-Rev ccb49abe412c978a4045f0c75abff534372716c4 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22 Build-ID 20141202001201 Version 34.0 Flame 2.2 version: Gaia-Rev 725685831f5336cf007e36d9a812aad689604695 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/2c9781c3e9b5 Build-ID 20141202040207 Version 37.0a1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: