-
Notifications
You must be signed in to change notification settings - Fork 712
Handle links that use third-party protocols or open external apps #32
Comments
@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?). |
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.
We should make sure both work acceptably. |
Fennec shows the following prompt when you open an external link in private browsing - I'll do the same in Focus for now: |
@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". |
// 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):
Open With
Exit Private Browsing? (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...) |
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): 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: 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. |
@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 :) |
(Note to self: I still need to set the right colours as per #32 (comment) , before closing) |
from Michelle:
|
"the" in the second sentence might be a problem. With placeholders (and without "the") the string would be:
And in the case of Google Play (app name = "Play Store") on my device this results in:
Is this acceptable? |
that is great, thanks for reviewing carefully and catching this! definitely remove the "the" |
One thing to note for the second (no-app) case:
(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.) |
(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.) |
@antlam Do we still want the blue title now that we're showing actual text (instead of the link): |
@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! |
Our link behaviour is:
|
No description provided.
The text was updated successfully, but these errors were encountered: