1346751 - Incoming tab isn't opened when notification is dismissed

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Android Sync, defect, P3)

Description

[Mark Hammond [:markh] [:mhammond]]

* Send a tab from desktop.
* Notice incoming notification - think "great!", but dismiss the notification.

Expected:
* Opening Firefox has the incoming tab available somewhere.

Actual:
* It doesn't - swiping the notification away lost the tab.

Comment 1

[Nick Alexander :nalexander [he/him]]

I think this was a product decision from way back in the day.  Before FxA and the work on tabs across your device constellation, we didn't have a place to store tabs like this.  Now, we should probably start doing things with them:
- put them in your tab queue
- put them in a section of tabs
- make sure they're in your history (useful for experts only?)

adavis, rfeeley, others: another thing that we should unify across Desktop, Android, and iOS.  Can you suggest what needs to be done for all of our clients?

Comment 2

[Ryan Feeley [:rfeeley]]

On Desktop, single or multiple received tabs open immediately as background tabs. Firefox remains in the background unless the notification is clicked. The notification for a single tab opens that tab. For multiple tabs, the notification the first tab of the batch is opened.

I think they should also open in Android in a similar fashion, even if the tab(s) are in the tab queue.

A notification is not the tab itself, it's a notification of a tab that has been received, and provides a direct link to the tab.

I'm not sure what you mean by "section of tabs".

Comment 3

[Nick Alexander :nalexander [he/him]]

(In reply to Ryan Feeley [:rfeeley] from comment #2)
> On Desktop, single or multiple received tabs open immediately as background
> tabs. Firefox remains in the background unless the notification is clicked.
> The notification for a single tab opens that tab. For multiple tabs, the
> notification the first tab of the batch is opened.
> 
> I think they should also open in Android in a similar fashion, even if the
> tab(s) are in the tab queue.

OK.  Historically this has been a little tricky on Android, since we couldn't start Gecko to open the tab in the background.  We should be able to do this now, keeping consistency across our platforms.

> A notification is not the tab itself, it's a notification of a tab that has
> been received, and provides a direct link to the tab.
> 
> I'm not sure what you mean by "section of tabs".

I meant the Tabs or Remote Tabs section in the home panels (or a subsection in the History panel, if that's what we do these days).

Comment 4

[:Grisha Kruglov]

I'd love for incoming tabs to somehow open in the browser, and we've had this discussion a couple of times now. It was an explicit decision _not_ to auto-open incoming tabs, but I'm happy to revisit if we can ensure a good experience.

Same discussion, 6 months ago: Bug 1300225.

Flagging antlam for mobile UX input.

Comment 5

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Bringing it back to comment 0, I think it makes sense to have *that* tab available, waiting, and loaded in the tabs tray/ somewhere in the "background". 

But, I think when we discussed it last, it was the "open and switch to it immediately" that didn't feel quite right.

Grisha, does this align with what you were thinking? Also happy to discuss further next week when I'm back :)

Comment 6

[Mark Hammond [:markh] [:mhammond]]

(In reply to Anthony Lam (:antlam) from comment #5)
> Bringing it back to comment 0, I think it makes sense to have *that* tab
> available, waiting, and loaded in the tabs tray/ somewhere in the
> "background". 
> 
> But, I think when we discussed it last, it was the "open and switch to it
> immediately" that didn't feel quite right.

That's exactly what I'm thinking :)

(And clearing all the needinfos - it sounds like we just need to work out the finer details...)

Comment 7

[Ryan Feeley [:rfeeley]]

Correct, it should never take you away from another app or another tab. It should provide parity with desktop by opening the tab in the background, only opening if the notification is tapped.

Comment 8

[Alex Davis [:adavis]]

(In reply to Ryan Feeley [:rfeeley] from comment #7)
> Correct, it should never take you away from another app or another tab. It
> should provide parity with desktop by opening the tab in the background,
> only opening if the notification is tapped.

+1

Comment 9

[:Grisha Kruglov]

Speaking of finer details, when we tap a notification a general OS intent to open a URL is sent out, specifically so that other applications more suitable than the browser might handle it (or even other browsers). Case in point: after receiving a Google Maps link, tapping it will open Google Maps native app with whatever directions, etc you've selected on desktop, which is an awesome feature.

Since we can't assume in advance if there is a better suited application installed on the phone for any given URL, we get something like the following flow:
- URL received
- if browser is running, open tab in the background and display a snackbar prompting user to switch. At the same time, a "heads-up" notification is displayed, which then becomes a regular notification in the notification panel
- if browser is not running, somehow persist information about this tab so that it will be opened on browser's launch. We have Tab Queue [0] on Fennec, that might be a good fit
- if notification is tapped and Fennec handles it, switch to the backgrounded tab - or launch Fennec and open the tab
- if notification is tapped and another app handles it, nothing happens in Fennec. We leave a background tab as is. This means that after "dealing" with the tab via another app, they'll still have a Fennec tab opened
- if notification is dismissed, do not dismiss the background tab
- if notification is ignored, do not dismiss the background tab

Overall this flow seems OK to me. I have a few concerns:
- handling of an incoming tab while browser isn't running. Some kind of integration with Tab Queue might be good. However, it's disabled by default, and I don't know how extensible that code is. At the very least we can mimick its approach, if not integrate with it directly. Overall this just feels like a can full of edge cases and side effects
- having a "duplicate" background tab in cases when incoming URL is handled externally seems like poor UX. Perhaps that's better than user accidentally loosing a tab though
- currently we just have the "display a heads-up notification" portion of this implemented. It's very unlikely that these improvements will make it into 53.

[0] https://support.mozilla.org/t5/Basic-Browsing/Open-links-in-the-background-for-later-viewing-with-Firefox-for/ta-p/27548

Comment 10

[Thom Chiovoloni [:tcsc] (ex-moco)]

From triage: ni?antlam to follow up on the comment above.

Comment 11

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to :Grisha Kruglov from comment #9)
> - if notification is tapped and Fennec handles it, switch to the
> backgrounded tab - or launch Fennec and open the tab

++ I like this!

> - if notification is tapped and another app handles it, nothing happens in
> Fennec. We leave a background tab as is. This means that after "dealing"
> with the tab via another app, they'll still have a Fennec tab opened

With this, I think we should separate it out as an Android Notification Action where we can. 

That is, if the notification is tapped, and another app handles it, still open in Fennec.

But if the notification ACTION is tapped, open it in the other app that handles it. We can use a system "share sheet" when there is more than 1 app that can handle this type of link.

As we talked about earlier, if the button here clearly describes this as an additional action "Also open in App" (for example, copy TBD), then I think its ok to also have the tab in Fennec.

Comment 12

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

NI so you're aware :)

Comment 13

[Barbara Bermes [:barbara] - NI please!]

Agree with the general approach of comment 7+8.

Comment 14

[Richard Newman [:rnewman]]

I agree that Comment 0 is a real issue.

Two concerns I haven't seen raised about the possible approaches:

- On Android, background applications can be quietly swapped out by the OS. From the user's perspective, there's no difference, except for a slower relaunch. Having different behavior for background-and-running versus background-and-terminated could be confusing for users: sometimes a sent tab will open, and sometimes it won't. (The user report would be "why does Firefox sometimes not show me that switch-to-tab grey blob when I send a tab to my phone? I have to go tap on the Firefox icon.")

- What happens if you send a tab that begins playing audio? What if it's a tab that downloads 4GB of ad data per day? What if it's just a big page, and it causes your phone to start killing background apps to free up memory, and so your music stops playing?

If we start opening incoming tabs immediately in the background, we would need to be really, really confident of our ability to open a tab in a paused/zombified state: no running JS, no media playing, no websockets, etc.

If we don't, then we'd be shipping a vector for Bug 1253346 regressions.


My personal opinion:

- If we can guarantee zombified tabs, then do approximately what Grisha suggests.
- If we can't, stuff the URL into the tab queue.


(In reply to :Grisha Kruglov from comment #9)

> - if notification is tapped and another app handles it, nothing happens in
> Fennec. We leave a background tab as is. This means that after "dealing"
> with the tab via another app, they'll still have a Fennec tab opened

We might be able to figure out if there are URL actions, and what the default is, and decide whether or not to open the tab in Fennec. I remember the Android APIs being buggy around this, though.

Comment 15

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.