Steps: * Do some browsing by clicking around. * Switch to email (I was using TouchDown, going through my morning mail). * Click a link. Fennec opens. * Hit the back button. Observe that the page title switches to the previous open page, and page load begins, before you return to your mail client. Looks like there are two back handlers firing or something.

Fennec does two things when you press the "back" button in an externally-opened tab: It closes the tab, and it sends itself to the background (so you return to your previous activity). It sounds like you are seeing the tab close (which will focus another tab, which will then start loading if it is a restored-but-not-loaded tab) before Fennec goes to the background. Ideally this should happen after Fennec is in the background, so the user doesn't see it.

(In reply to Matt Brubeck (:mbrubeck) from comment #1) > It sounds like you are seeing the tab close (which will focus another tab, > which will then start loading if it is a restored-but-not-loaded tab) before > Fennec goes to the background. Ideally this should happen after Fennec is > in the background, so the user doesn't see it. That sounds like what's happening, yes. I don't think this should be a user-visible event; it isn't in the stock browser. Very disconcerting to see.

Fennec calls moveTaskToBack before calling closeTab, but the actual backgrounding of the app is async so it might not happen until after the tab close. We could wrap the closeTab in a 1-second timeout or something, to make this less likely. https://hg.mozilla.org/mozilla-central/file/ee38392142ed/mobile/android/base/GeckoApp.java#l2597

That, or do this backward: don't track these external tabs in the same way as a user-created tab. Don't restore them onResume, for example. Hitting back should just pop the activity, and resuming GeckoApp can do the right thing.

Lucas, this sounds like a UX responsiveness issue.

Is this bug the same issue as bug 835012?

(In reply to :Margaret Leibovic from comment #6) > Is this bug the same issue as bug 835012? Looks like it, albeit with different back behavior (returning to about:home rather than a previous history item). The competing 'back's are still there.

Marking this as a dupe since bug 835012 has a patch.