Skip to content
This repository has been archived by the owner on Jan 12, 2023. It is now read-only.

Handle links that use third-party protocols or open external apps #32

Closed
pocmo opened this issue Jan 26, 2017 · 18 comments
Closed

Handle links that use third-party protocols or open external apps #32

pocmo opened this issue Jan 26, 2017 · 18 comments

Comments

@pocmo
Copy link
Contributor

pocmo commented Jan 26, 2017

No description provided.

@ahunt
Copy link
Contributor

ahunt commented Feb 22, 2017

@antlam : What behaviour do we want? A user is unlikely to know that a link will redirect to an external app until they've clicked on it - do we need a notification to confirm that they are leaving focus (and do we need to ask them if they want to clear their browsing data then?).

@ahunt
Copy link
Contributor

ahunt commented Feb 22, 2017

Note to whoever implements this: behaviour when opening a link from scratch (i.e. start focus, paste link) is different to behaviour when opening a link when you're already browsing.

  • Opening link: shouldOverrideUrlLoading() is called, followed by shouldInterceptRequest()
  • Opening from scratch: we've added notifyCurrentURL (since shouldOverrideUrlLoading() isn't called in this case), followed by shouldIntereceptRequest().

We should make sure both work acceptably.

@ahunt ahunt self-assigned this Feb 28, 2017
@ahunt ahunt added this to the Sprint 1 milestone Feb 28, 2017
@ahunt
Copy link
Contributor

ahunt commented Feb 28, 2017

Fennec shows the following prompt when you open an external link in private browsing - I'll do the same in Focus for now:
URL
This link will open in Google Play Store. Are you sure you want to exit Private Browsing?
[No] [Yes]

@antlam
Copy link
Contributor

antlam commented Feb 28, 2017

@ahunt perfect! that's exactly what I was going to say 💯

But instead of "Private Browsing" perhaps we should use the product name. That is, "Firefox Focus".

@ahunt
Copy link
Contributor

ahunt commented Feb 28, 2017

// Edit: disregard - I've spoken to antlam, and we'll stick with the firefox for android behaviour right now. I'll try to put a document together with screenshots/descriptions in case we want to revisit this.

One more UX thing: If there are multiple apps that support a given link (e.g. email):

  • Firefox normal browsing:
    -- If a default app is set, the app is opened directly
    -- If no default app exists:

Open With
[App 1]
[App ...N]
[Just once] [Always]

  • Firefox private browsing: if more than one app is available, we always show:

Exit Private Browsing?
[App 1] [App 2]...[App3]

(We're using the OS app picker for both, but on at least Android 7 one of those is horizontal, and one is vertical. We don't show which app is the default for private browsing, but it's still possible for us to ask Android which one is the default.)

For now I've copied the firefox private browsing mode behaviour. I'm wondering if it's better to just try to use the default app if one is set (we don't offer that choice in normal browsing after all)? We could still add a "open in other app" option to the "exit focus" confirmation dialog in this scenario.

(I have screenshots, but screenshot upload is failing today...)

@ahunt
Copy link
Contributor

ahunt commented Mar 1, 2017

Here's a screenshot of the current dialog (I haven't done anything related to its appearance, that's just the default dialog appearance with our current theme) - I'm not sure that using the link as a title is ideal (that's what fennec does):
dialog_preview

I'm also not too sure what exactly to show if we need to redirect to the play store, this is the current state of things:
dialog_play

Finally, I still need to handle completely unsupported links: we can only redirect to the play store if a link contains an android app/package name (so generic random schemes won't do anything, e.g. ssh://...... is ignored). I still need to add code to handle that case, for now I'm redirecting to a non-existent about:error page.

I've also put together a quick document summarising what various browsers do when opening external links, just in case we need to revisit our behaviour decision.
https://docs.google.com/a/mozilla.com/document/d/1KZVpSpptLsfv72qLEUXooxwM2bgcW0qWT4g2h_9bMpM/edit?usp=sharing

@antlam
Copy link
Contributor

antlam commented Mar 2, 2017

@ahunt For the link/buttons, can we use the blue we're using in the Settings UI?

For the "No app to handle link" I'll ask Michelle.

Also thanks for the doc! it's really helpful :)

@ahunt
Copy link
Contributor

ahunt commented Mar 14, 2017

(Note to self: I still need to set the right colours as per #32 (comment) , before closing)

@ahunt
Copy link
Contributor

ahunt commented Mar 14, 2017

How's this?
updatedstyle

@antlam
Copy link
Contributor

antlam commented Mar 15, 2017

from Michelle:

For the case where there is an app that can handle the link, instead of showing the link how about:
Open link in another app
You can leave Firefox Focus to open this link in .
CANCEL | OK

For the case where there is no app to handle this link:
Find an app that can open link
None of the apps on your device can open this link. You can leave Firefox Focus to search the Google Play Store for an app that can.
CANCEL | OK

@pocmo
Copy link
Contributor Author

pocmo commented Mar 15, 2017

None of the apps on your device can open this link. You can leave Firefox Focus to search the Google Play Store for an app that can.

"the" in the second sentence might be a problem. With placeholders (and without "the") the string would be:

None of the apps on your device can open this link. You can leave %1$s to search %2$s for an app that can.

And in the case of Google Play (app name = "Play Store") on my device this results in:

None of the apps on your device can open this link. You can leave Firefox Focus to search Play Store for an app that can.

Is this acceptable?

@mheubusch
Copy link

that is great, thanks for reviewing carefully and catching this! definitely remove the "the"

@ahunt
Copy link
Contributor

ahunt commented Mar 15, 2017

One thing to note for the second (no-app) case:

  • The link might contain an app ID, in which case we can ask to open google play to allow looking at that specific app. This is what firefox already does, and what we already have in focus. (Note: we don't have access to the app name, only the app id, which might be something like org.mozilla.firefox).
  • The link might not contain an app ID - in which case it's a trickier, since the user might not even know what to search for. The play store doesn't let us search by link/protocol type, so all we're doing is dumping them into the play store with a probably cryptic link as their only hint. (Firefox does absolutely nothing in this situation, right now focus redirects to a page explaining that this protocol isn't supported).

(Opening the play store to search for an unspecified app doesn't seem too helpful IMHO, since research will be needed to find out what app might support a specific protocol. Websites aren't likely to use a weird protocol in the first place because of this.)

@ahunt
Copy link
Contributor

ahunt commented Mar 16, 2017

(FWIW Chrome also does nothing if you have an unsupported link (e.g. ssh:......). It only opens the play store if the link specifies the exact desired app.)

@ahunt
Copy link
Contributor

ahunt commented Mar 16, 2017

@antlam Do we still want the blue title now that we're showing actual text (instead of the link):
v3_1

@antlam
Copy link
Contributor

antlam commented Mar 16, 2017

@ahunt

@antlam Do we still want the blue title now that we're showing actual text (instead of the link):

Nope! Keep it white :)

@antlam
Copy link
Contributor

antlam commented Mar 16, 2017

@ahunt can you quickly comment in here when you have the chance? just to summarize what we decided for the 1% use case and the 99% use case :)

Thanks!

@ahunt
Copy link
Contributor

ahunt commented Mar 22, 2017

Our link behaviour is:

  • Normal web link -> open it
  • External link: multiple scenarios:
    -- Link handled by existing app:
    --- Show confirmation dialog if only one target app exists
    --- Show selector if multiple target apps exist
    -- No target app exists:
    --- Link includes target app (e.g. a link designed to open yelp/google play/etc): we ask to open the Play Store [This is likely for 99% of links that aren't an email address or phone number]
    --- Link doesn't include target app: show error page (Note: both Chrome and Firefox do nothing in this scenario) [1% scenario]

@ahunt ahunt closed this as completed Mar 22, 2017
@pocmo pocmo modified the milestone: 1.0 Jul 26, 2017
@pocmo pocmo unassigned ahunt Jul 26, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants