Closed Bug 966323 Opened 7 years ago Closed 7 years ago

[B2G] Email account unrecognizable when sharing a link from the browser


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

Gonk (Firefox OS)
Not set


(blocking-b2g:1.4+, b2g-v1.2 unaffected, b2g-v1.3 wontfix, b2g-v1.4 fixed, b2g-v2.0 fixed)

1.4 S6 (25apr)
blocking-b2g 1.4+
Tracking Status
b2g-v1.2 --- unaffected
b2g-v1.3 --- wontfix
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed


(Reporter: selkabule, Assigned: mcav)


(Keywords: regression, Whiteboard: dogfood1.3 [p=3])


(2 files)

When having a valid email set previously in Email app, and selecting the share button from the browser. The device will display a message "You are not set up to send or receive email. Would you like to do that now" 

Prerequisites: Email already configured in the Email application

Repro Steps:
1) Updated Buri to Build ID: 20140127004002
2) Open the Browser and go to
3) Select the share button from the application bar

The device will display the message "You are not set up to send or receive email. Would you like to do that now" 

The device should transfer the user to the Email application with the link ready to share 

Environmental Variables
Device: Buri 1.3 MOZ RIL
Build ID: 20140127004002
Gaia: 25a45a836a4a21a30f63fa7b544b42e8b781180a
Platform Version: 28.0a2
Firmware Version: v1.2-device.cfg

Repro frequency: the issue is very intermittent, happens randomly in ~10%
See attached: Video clip (, logcat
This issue does not reproduce on buri V1.2

Environmental Variables:
Device: Buri 1.2 MOZ
BuildID: 20140128004004
Gaia: 539a25e1887b902b8b25038c547048e691bd97f6
Gecko: d10e1f965d0c
Version: 26.0
Firmware Version: V1.2-device.cfg

The device transfers the user to the Email application with the link ready to share
QA Contact: astole
Feels minor - irrelevant UX is showing up, but it looks like you recover quickly. Additionally, the probability of reproduction is low, so I think we can live with this.
Component: Gaia::System::Window Mgmt → Gaia::E-Mail
nominating for 1.4? Triage team.
blocking-b2g: --- → 1.4?
There might be a race related to the acctsSlice.  Model.init() only emits 'acctsSlice' in the oncomplete notification, but it does assign the accounts slice to Model.acctsSlice when it's opened.  Because of how the logic for latestOnce() works, by having acctsSlice assigned to on the Model, latestOnce() may synchronously trigger the passed-in listener before 'oncomplete' has fired.  (The extra wrinkle is that if _pendingEvents['acctsSlice'] is truthy, we will defer until the event really fires.

The varying bits are likely:
- How long it takes the back-end to start up
- When the 'activity' message is actually delivered after we register for it using navigator.mozSetMessageHandler.

If there's no logic that blindly assumes acctsSlice exists, we can defer assigning it to Model until its oncomplete event fires.  If there is logic that assumes it exists, we could add a separate field to save it to and also emit that event too.  For example, 'populatedAcctsSlice'.
blocking-b2g: 1.4? → 1.4+
Assignee: nobody → m
Target Milestone: --- → 1.4 S6 (25apr)
Blergh. I'm having trouble getting my ZTE device to get networking, so I haven't had a chance to test this on-device yet. When I head home tonight I'll have access to a SIM card that I can try. Leaving off the review flag for now until I can test it on-device.
I've found when wi-fi is having troubles on the devices that rebooting them sometimes fixes it.  I've definitely freshly flashed a device, had wi-fi not work, then rebooted to great success.  This does assume there's no causal problem such as the permissions being wrong on the wpa_supplicant/etc, of course.
Retriage - this is a minor bug, so we might be able to live with this.
blocking-b2g: 1.4+ → 1.4?
Tony was present at the triage decision on this, although I realize our triage rationale was not included in the bug, so it seems like we have a triage work-flow problem.  Should we be more verbose when blocking+-ing something to avoid request churn?

The rationale I had for suggesting we + this was that if you hit this race and we prompt you to re-create the account, it can be very confusing to the user since they may then say "yes, let's add the account."  They then end up in the add the account dialog (with no back button!).  Then they enter the info and we will detect a duplicate account and refuse to create the account.  Now the user is confused because we refuse to let them create the account and we refuse to let them back out of creating the account.  They would have to know to manually close the app.  Then there's still a chance of a probabilistic failure the next time they use this same path.
On comment 5 and comment 6 about troubles testing on wifi, this week I have had trouble configuring a hidden network because of bug 996869.
1.4+ for bad UX as described in comment 8
blocking-b2g: 1.4? → 1.4+
Comment on attachment 8407208 [details] [review]
Link to Github pull-request:

With the current patch, I was able to share a link (from a clean, no-email-process-running) 5/5 times successfully with an account already set up. However, I was unable to reproduce the issue on master, so I cannot definitively say that this patch fixes the issue.

There definitely was a race condition per :asuth's comment, so if that was indeed causing the issue, this should address it.
Attachment #8407208 - Flags: review?(bugmail)
Comment on attachment 8407208 [details] [review]
Link to Github pull-request:

Great unit test, thanks!
Attachment #8407208 - Flags: review?(bugmail) → review+
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: dogfood1.3 → dogfood1.3 [p=3]
Gaia      d23e479e8a4ce0bc620acb2d7e2f82801aa4d0ea
BuildID   20140427000203
Version   30.0a2 Dec 19 14:04:55 CST 2013

You need to log in before you can comment on or make changes to this bug.