About 50% of the time when I choose Share from another app (usually K-9 or Plume) and choose Firefox Sync as the target, the resulting "Send Tab to Devices" dialog opens with no devices listed. If I immediately hit the Back button and then try again, I get all the devices on the second attempt. With it hooked up to a laptop with a USB cable, and observing the log both when it does have devices listed and when it doesn't, the only difference between the two is when the devices *don't* show up, the log has this additional entry: > W | 04-09 01:17:27.884 | 11288 | org.mozilla.fennec | GeckoAnnounce | fennec :: SendTabActivity :: No tab sender when fetching other client IDs.

Firefox 31.0a1 (2014-04-08) Samsung Galaxy S4 SCH-I545 Android 4.3

SendTabActivity.onCreate calls updateClientList, which spawns a background task to fetch clients, which involves fetching clients, which touches tabSender. SendTabActivity.onResume is what sets tabSender. The background task is racing when the activity is created. When it works, either the race runs the other way, or the same activity is being resumed (and no new activity needs to be created). I think the onResume/onCreate division in this class needs to be made sane…

I'm not entirely sure if this is Android-specific... or if it's separately implemented in the same broken fashion. I just reproduced this in the desktop version of Send-tab-to-device implemented by https://addons.mozilla.org/en-US/firefox/addon/send-tab-to-device/

Untested. Feedback, Michael?

Comment on attachment 8467502 [details] Pull req. v1 Assuming your diagnosis was correct, looks like a reasonable solution to me.

Comment on attachment 8467502 [details] Pull req. v1 Updated PR lgtm. Just don't forget to test it. ;)

Comment on attachment 8467502 [details] Pull req. v1 Approval Request Comment Requesting uplift to 33 -- setting Beta 'cos it's merge day. [Feature/regressing bug #]: Long-standing race condition. [User impact if declined]: Some users see this a lot; others less often. Send Tab is unusable if it occurs. [Describe test coverage new/current, TBPL]: Manual testing only. [Risks and why]: Should be relatively slim. The patch is mostly a reordering of operations to match Android lifecycles. [String/UUID change made/needed]: None.

FWIW this has been working fantastic on Nightly the last couple days. I was running into this constantly, and it's *SO* nice to have it work on the first try every time now.

Glad to hear it, Dave. Thanks.