Closed Bug 1173147 Opened 6 years ago Closed 6 years ago

Prompt the user when opening intent URIs in private browsing mode

Categories

(Firefox for Android Graveyard :: General, defect)

All
Android
defect
Not set
normal

Tracking

(firefox44 fixed, relnote-firefox 44+, fennec44+)

RESOLVED FIXED
Firefox 44
Tracking Status
firefox44 --- fixed
relnote-firefox --- 44+
fennec 44+ ---

People

(Reporter: mcomella, Assigned: mcomella)

References

Details

(Keywords: privacy, sec-want, Whiteboard: [adv-main44-]forced de-privatization)

Attachments

(7 files, 2 obsolete files)

201.78 KB, image/png
Details
40 bytes, text/x-review-board-request
sebastian
: review+
Details
40 bytes, text/x-review-board-request
sebastian
: review+
Details
40 bytes, text/x-review-board-request
sebastian
: review+
Details
91.78 KB, image/png
antlam
: feedback+
Details
40 bytes, text/x-review-board-request
sebastian
: review+
Details
40 bytes, text/x-review-board-request
sebastian
: review+
Details
Wes has mentioned that the user experience when the user clicks a link and an app opens is intuitive and potentially a security risk (e.g. user thinks they're still in Firefox) - see bug 851693 comment 5 and subsequent comments. He would like to prompt the user to essentially tell them they are leaving Firefox.

I feel this is a good idea, though I wonder how this will compare with Google's approach of removing the abstraction of a browser and making things seem like a contiguous experience.

Anthony, what are your thoughts here? I'm thinking we could do a dialog that says, "This link will open an external application which could potentially be harmful. etc. etc." See my example attachment.
Flags: needinfo?(alam)
Assignee: nobody → michael.l.comella
Hm, I'm hesitant to lean towards this direction. I'm not too worried that users will think they're still in Firefox. App linking is a pretty obvious interaction at this point and I don't think it's a big security risk.

My first impression from seeing this dialog is that I'm a bit taken back. As a user, I somewhat expect this to "just work" and this adds a lot of friction to that process. I feel like most of the time, we will be making a big deal (drawing a lot of attention to) something that isn't really that scary. Not to mention, we're not really offering a solution after making a (somewhat) big deal of it.

For me, this is a WONTFIX right now. Maybe we can figure out a way to separate out the more "untrusted" links or even make it more obvious that pressing an intent link will jump you out of Firefox, but to do this for every intent will be too jarring.
Flags: needinfo?(alam)
I'm not that worried about where the user thinks they are (an intent could open something semi-transparent to grab touches on the web page, but that requires malware already installed). I worry a bit more about whether an exploit in a third party app can be triggered by sending some malformed intent data. We don't auto-open downloads because of that sort of thing.
(In reply to Wesley Johnston (:wesj) from comment #2)
> I worry a bit more about whether an exploit in a third party app can be
> triggered by sending some malformed > intent data.

So the third party app being the app receiving the Intent URI? It's worth noting that we provide CATEGORY_BROWSABLE [1] to the Intent, which is only supposed to open Activities that can safely handle content from the web. Are you concerned that these third party apps receiving the Intent with CATEGORY_BROWSABLE will have exploits from malformed Intent data anyway?

What text would you expect to see in the prompt?

[1]: https://developer.android.com/reference/android/content/Intent.html#CATEGORY_BROWSABLE
Flags: needinfo?(wjohnston)
(In reply to Michael Comella (:mcomella) from comment #3)
> Are you concerned that these third party apps receiving the Intent with
> CATEGORY_BROWSABLE will have exploits from malformed Intent data anyway?
Yes. I have no trust for our code, let alone others. FWIW, we've made ourselves feel slightly better about this before by making sure we had a pref to short circuit the behavior (flippable in a quick hot-fix should we need to).

> What text would you expect to see in the prompt?
"Open this link in <blank>". "Always", "Once", "Cancel"
Flags: needinfo?(wjohnston)
I'm going to NI Matej here for some copy.

Matej, feel free to read up for some added context but basically...

A user is in Private browsing mode > they hit a link that opens something like an application (think google play store, youtube, etc). At this moment, we'd like the user to be aware of the implications of their actions but we don't want to make a huge deal out of it (they're already getting surprised because what they pressed appeared to be a link like any other). 

Could you recommend some brief copy to tell users they they're leaving our "protective bubble"? I guess this would also go hand in hand with the about:privatebrowsing copy you did for bug 1187984 :)
Flags: needinfo?(matej)
Here are a few options. Let me know if these are on the right track:

You are about to leave Firefox and Private Browsing. Do you want to continue?

You are about to leave Firefox. This will end your private session. Do you want to continue?

This link will open in <app>. Are you sure you want to exit Private Browsing?
Flags: needinfo?(matej)
I like the last one! It gives great context while being brief, and without repeating ourselves too much.

"This link will open in <app>. Are you sure you want to exit Private Browsing?"

I think with the dialog title, this one works. Thoughts Mike?
Flags: needinfo?(michael.l.comella)
(In reply to Anthony Lam (:antlam) from comment #7)
> "This link will open in <app>. Are you sure you want to exit Private
> Browsing?"

I think we can get the app name, but I'm not positive.

Also, this should also affect non-private browsing use case scenarios - how do you want to change the copy to compensate?

> I think with the dialog title, this one works. Thoughts Mike?

What is the dialog title?
Flags: needinfo?(michael.l.comella) → needinfo?(alam)
(In reply to Michael Comella (:mcomella) from comment #8)
> (In reply to Anthony Lam (:antlam) from comment #7)
> > "This link will open in <app>. Are you sure you want to exit Private
> > Browsing?"
> 
> I think we can get the app name, but I'm not positive.
> 
> Also, this should also affect non-private browsing use case scenarios - how
> do you want to change the copy to compensate?

Hm, I'm still hesitant to add an interstitial to this experience for normal browsing. Especially since I think it'll be rather unexpected for our users. 

While I see the security risks... I think not all of these types of links are bad. And in fact most of them aren't. So, adding an extra step to every link seems a bit much.

Perhaps you could help me understand why this needs to be added to the normal browsing experience?
 
> > I think with the dialog title, this one works. Thoughts Mike?
> 
> What is the dialog title?

In the screenshot above, it was the "lyft.com/line"
Flags: needinfo?(alam)
Anthony and I decided via Vidyo that the user experience of prompting for every link would be frustrating so we should just prompt in PB mode.
Summary: Prompt the user when opening intent URIs → Prompt the user when opening intent URIs in private browsing mode
Duplicate of this bug: 1186423
Moving tracking flag from Bug 1186423.
tracking-fennec: --- → 43+
Duplicate of this bug: 1153087
I'm using DialogFragment to construct the dialog but we can't use it because of bug 1201206 – we'll see what the resolution is before I determine how to proceed.
Bug 1173147 - Add Intent in private browsing prompt string. r=sebastian
Attachment #8662117 - Flags: review?(s.kaspari)
Bug 1173147 - Add DialogFragment to prompt user when clicking Intent link in private browsing. r=sebastian

Note that the DialogFragment is currently unused and will be used in the
followup changesets.
Attachment #8662118 - Flags: review?(s.kaspari)
Bug 1173147 - Prompt user when opening market intent. r=sebastian
Attachment #8662119 - Flags: review?(s.kaspari)
This changeset series is incomplete: we still need to fire the DialogFragment when clicking arbitrary links (which is much messier).
Btw. I pulled the changes from reviewboard and the build of geckoview_library is failing:

> 0:14.79      [aapt] /Users/sebastian/Projects/Mozilla/fx-team/objdir-frontend/mobile/android/geckoview_library/res/values-v21/styles.xml:12: error: Error retrieving parent for item: No resource found that matches the given name '@style/ThemeOverlay.AppCompat.ActionBar'.
> 0:14.79      [aapt]
> 0:14.79      [aapt] /Users/sebastian/Projects/Mozilla/fx-team/objdir-frontend/mobile/android/geckoview_library/res/values/themes.xml:12: error: Error retrieving parent for item: No resource found that matches the given name 'Theme.AppCompat.Light.DarkActionBar'.
> 0:14.79      [aapt]
> 0:14.79      [aapt] /Users/sebastian/Projects/Mozilla/fx-team/objdir-frontend/mobile/android/geckoview_library/res/values-v11/themes.xml:12: error: Error retrieving parent for item: No resource found that matches the given name 'Theme.AppCompat.Light.DarkActionBar'.
> 0:14.79      [aapt]
> 0:14.79      [aapt] /Users/sebastian/Projects/Mozilla/fx-team/objdir-frontend/mobile/android/geckoview_library/res/values-v21/themes.xml:11: error: Error retrieving parent for item: No resource found that matches the given name 'Theme.AppCompat.Light.DarkActionBar'.

This would require geckoview_library to include Appcompat?
Attachment #8662117 - Flags: review?(s.kaspari) → review+
Comment on attachment 8662117 [details]
MozReview Request: Bug 1173147 - Add Intent in private browsing prompt string. r=sebastian

https://reviewboard.mozilla.org/r/19519/#review17557
Comment on attachment 8662118 [details]
MozReview Request: Bug 1173147 - Add DialogFragment to prompt user when clicking Intent link in private browsing. r=sebastian

https://reviewboard.mozilla.org/r/19521/#review17559

::: mobile/android/base/widget/ExternalIntentDuringPrivateBrowsingPromptFragment.java:55
(Diff revision 1)
> +    public void showDialogOrAndroidChooser(final Context context, final Intent intent,

Could this be static (and the fragment object be created inside)? This would avoid creating a fragment object in cases where we actually do not show the dialog.

::: mobile/android/base/widget/ExternalIntentDuringPrivateBrowsingPromptFragment.java:63
(Diff revision 1)
> +            matchingApplicationName = matchingActivities.get(0).loadLabel(pm);

This value might not survive recreating the fragment (what fragment manager normally does on device rotation, or when the activity is recreated). Instead (if this is static and the fragment is created here, see above) use setArguments() and read the argument(s) in onCreateDialog().
Attachment #8662118 - Flags: review?(s.kaspari)
Comment on attachment 8662119 [details]
MozReview Request: Bug 1173147 - Prompt user when opening market intent. r=sebastian

https://reviewboard.mozilla.org/r/19523/#review17561

::: mobile/android/base/IntentHelper.java:219
(Diff revision 1)
> +            fragment.showDialogOrAndroidChooser(activity, intent, activity.getSupportFragmentManager(), "IntentHelper");

I wonder if the tag is something that should be handled internally by ExternalIntentDuringPrivateBrowsingPromptFragment. Do callers care?
Attachment #8662119 - Flags: review?(s.kaspari)
Release Note Request (optional, but appreciated)
[Why is this notable]: We implemented intent uri support in bug 851693, which allows users to click links that open external Android applications. However, users in private browsing mode may click a link, open an external app, and have their private data leaked. This bug will prompt the user before they exist private browsing mode.

Note that custom URI schemes, which can also open external android apps, may be a follow-up bug depending on complexity.

[Suggested wording]: Prompt user before opening [Intent URIs] in a Private Browsing tab

[Intent URIs]: https://developer.chrome.com/multidevice/android/intents

[Links (documentation, blog post, etc)]: See above
relnote-firefox: --- → ?
https://reviewboard.mozilla.org/r/19521/#review17559

> Could this be static (and the fragment object be created inside)? This would avoid creating a fragment object in cases where we actually do not show the dialog.

Hell yeah! This cleans up a lot. :)
Comment on attachment 8662118 [details]
MozReview Request: Bug 1173147 - Add DialogFragment to prompt user when clicking Intent link in private browsing. r=sebastian

Bug 1173147 - Add DialogFragment to prompt user when clicking Intent link in private browsing. r=sebastian

Note that the DialogFragment is currently unused and will be used in the
followup changesets.
Attachment #8662118 - Flags: review?(s.kaspari)
Comment on attachment 8662119 [details]
MozReview Request: Bug 1173147 - Prompt user when opening market intent. r=sebastian

Bug 1173147 - Prompt user when opening market intent. r=sebastian
Attachment #8662119 - Flags: review?(s.kaspari)
(Still need to get random links from web content working)
Comment on attachment 8662118 [details]
MozReview Request: Bug 1173147 - Add DialogFragment to prompt user when clicking Intent link in private browsing. r=sebastian

https://reviewboard.mozilla.org/r/19521/#review17665

Yeah, nice! :)

::: mobile/android/base/widget/ExternalIntentDuringPrivateBrowsingPromptFragment.java:72
(Diff revision 2)
> +            args.putCharSequence(KEY_APPLICATION_NAME, matchingActivities.get(0).loadLabel(pm));

Interesting that this returns a CharSequence and not a String.
Attachment #8662118 - Flags: review?(s.kaspari) → review+
Comment on attachment 8662119 [details]
MozReview Request: Bug 1173147 - Prompt user when opening market intent. r=sebastian

https://reviewboard.mozilla.org/r/19523/#review17673
Attachment #8662119 - Flags: review?(s.kaspari) → review+
(In reply to Anthony Lam (:antlam) from comment #9)
> Hm, I'm still hesitant to add an interstitial to this experience for normal
> browsing. Especially since I think it'll be rather unexpected for our users. 

As a platform comparison, on Desktop Firefox we ask (by default) before launching an external app with a few carefully considered exceptions of "expected behavior"--primarily the mailto: scheme. See the network.protocol-handler. prefs. Of course the user can choose to "always" open links of any type in the future. We can add android-specific things here, but we shouldn't be short-circuiting the concept.

> While I see the security risks... I think not all of these types of links
> are bad. And in fact most of them aren't. So, adding an extra step to every
> link seems a bit much.

If we knew which types of links were bad we simply wouldn't open them! 99.9% of links are fine, the ones that are going to get users are the oddball pre-installed apps that everyone forgets about--including the creators--that are quick cash-in security cesspools. Then someone figures out how to abuse it and without any speedbump at all you can spam ads to millions of people and be unstoppable. For apps that users encounter all the time (PDFs, for example, or tel: links) the user will quickly select the "Always" button rather than the "Just Once" one, and that's fine -- apps that are commonly used get a lot more security attention and love and more likely to get updated.

Private browsing (as this bug morphed to cover) adds another wrinkle: forced de-anonymization even if the outside app is perfectly safe and working as designed (depends on the app, of course, but attackers would pick the useful ones).

> Perhaps you could help me understand why this needs to be added to the
> normal browsing experience?

My own phone seems to ask me before launching apps. It's possible this is a setting I've turned on (I'm like that, but I can't find one) but I think this is just normal behavior when you haven't set default apps. I always pick the "Just Once" option and it keeps asking -- annoying but safe :-)

Is that just because the intents were non-specific, or would that always be true until the user picks "Always"? If android already has that UI, and it _always_ comes up, then apart from the Private Browsing issue we could just leave it up to the user's choice on Android. The ones they use they will allow permanently, and the pre-installed crap I worry about wouldn't have been used and will get the dialog from the OS.
Keywords: privacy, sec-want
Whiteboard: forced de-privatization
NI self to respond to comment 30 on Monday.
Flags: needinfo?(michael.l.comella)
(In reply to Daniel Veditz [:dveditz] from comment #30)
> As a platform comparison, on Desktop Firefox we ask (by default) before
> launching an external app with a few carefully considered exceptions of
> "expected behavior"--primarily the mailto: scheme.

When the user has no choice about which app to open (e.g. an explicit Intent to open an explicit Activity or there is only one app installed that passes the Intent filters), Android by default does not prompt the user that an app will be opened. By not prompting the user in the general case (except when there are multiple application matches), we are (to a certain extent) following platform convention.

> If we knew which types of links were bad we simply wouldn't open them!

I think there is an assumption here that the number of vulnerabilities is more limited on Android:
  * In order for the exploit to occur, an app with a vulnerability has to already exist on the device. The number of users affected by this is reduced to the app's install base. I'd also assume the number of vulnerabilities is limited compared to desktop's problem of websites running arbitrary code in your browser but maybe that's incorrect.
  * The receiving Activities are limited to those with the CATEGORY_BROWSABLE Intent category, which explicit says they are prepared to handle arbitrary content from a website. Not a perfect fix, but it prevents applications from being caught off-guard.

There is something to be said for the user having to first install the apps which contain vulnerabilities – we can't spend too much effort trying to protect the user from actions outside of our jurisdiction. However, if there is a minimal effort solution that doesn't annoy the remainder of our users, we can try.

> 99.9% of links are fine, the ones that are going to get users are the oddball
> pre-installed apps that everyone forgets about--including the creators--that
> are quick cash-in security cesspools.

Is there a prevalence of pre-installed apps with security exploits? If so, it might make more sense to protect the user more heavily.

> Private browsing (as this bug morphed to cover) adds another wrinkle: forced
> de-anonymization even if the outside app is perfectly safe and working as
> designed (depends on the app, of course, but attackers would pick the useful
> ones).

I don't understand what you mean by this – are you concerned there could be an exploit around the prompt being created in this bug where a malicious app might de-anonymize the user?

> My own phone seems to ask me before launching apps.

As I mentioned before, Android does not do this by default. I've noticed on my Samsung phone that the default applications do prompt you (e.g. opening a link from an SMS) but the system does not (e.g. Facebook won't prompt).
Flags: needinfo?(michael.l.comella)
Attached image Explicit android chooser dialog (obsolete) —
My current approach is:
  * If not pb, open the Intent URI
  * If pb and one matching application, show this dialog
  * If pb and > 1 matching application, show the Android system chooser

However, I have no way of distinguishing between a normal and pb tab to the Android system when opening an Intent. This means links that you set as "Open with always" in normal mode will automatically open in private browsing.

I found a way to explicitly show the Android system chooser to get around this issue but it does not include an "Always" button. We have the ability to set the title, presumably to something like, "Leave Private Browsing?". See the attached screenshot to get an idea (the title is "lol").

What do you think, Anthony? Do you have any better ideas? If not, what should the title be?

Some ways to build upon this in the future (follow-up?):
  * We can use the Android APIs from under the hood to build our own custom chooser. The only problem is we'd then have to update it to match the system, or do our own style (e.g. if we have the same explanation test)
  * The explicit system chooser tells you which option is selected by the user – perhaps we can use that information to create our own "Always" prompt for the next time the user opens a link.
Flags: needinfo?(alam)
Talked to Mcomella on IRC. It looks like the is the best option for now.

(In reply to Michael Comella (:mcomella) from comment #33)
> Created attachment 8663952 [details]
> Explicit android chooser dialog
> 
> My current approach is:
>   * If not pb, open the Intent URI
>   * If pb and one matching application, show this dialog
>   * If pb and > 1 matching application, show the Android system chooser

To be clear, we're just talking about the 3rd bullet point (mentioned above) here.

Reading back above, Matej suggested copy that would probably work well here.

(In reply to Matej Novak [:matej] from comment #6)
> Here are a few options. Let me know if these are on the right track:
> 
> You are about to leave Firefox and Private Browsing. Do you want to continue?
> 
> You are about to leave Firefox. This will end your private session. Do you
> want to continue?
> 
> This link will open in <app>. Are you sure you want to exit Private Browsing?

Since we went with:

> This link will open in <app>. Are you sure you want to exit Private Browsing?

Let's try "Are you sure you want to exit Private Browsing?" followed by the app list.
Flags: needinfo?(alam) → needinfo?(michael.l.comella)
Flags: needinfo?(michael.l.comella)
Attached image Explicit android chooser dialog (obsolete) —
Attachment #8663952 - Attachment is obsolete: true
Attachment #8664581 - Flags: feedback?
Attachment #8664581 - Flags: feedback? → feedback?(alam)
Comment on attachment 8664581 [details]
Explicit android chooser dialog

+ for the string/copy

The padding and everything around that looks off-spec though. I feel like we need to add some padding. Is this the default Android styling?
Flags: needinfo?(michael.l.comella)
Attachment #8664581 - Flags: feedback?(alam) → feedback+
(In reply to Anthony Lam (:antlam) from comment #36)
> The padding and everything around that looks off-spec though. I feel like we
> need to add some padding. Is this the default Android styling?

Spoke on IRC – we can't change the style because it's a system dialog so we're going to try to shorten the copy to keep it one line: "Exit Private Browsing?"
Flags: needinfo?(michael.l.comella)
Attachment #8664581 - Attachment is obsolete: true
Attachment #8665140 - Flags: feedback?(alam)
Comment on attachment 8665140 [details]
Explicit android chooser dialog v3

WFM!
Attachment #8665140 - Flags: feedback?(alam) → feedback+
Comment on attachment 8662117 [details]
MozReview Request: Bug 1173147 - Add Intent in private browsing prompt string. r=sebastian

Bug 1173147 - Add Intent in private browsing prompt string. r=sebastian
Comment on attachment 8662118 [details]
MozReview Request: Bug 1173147 - Add DialogFragment to prompt user when clicking Intent link in private browsing. r=sebastian

Bug 1173147 - Add DialogFragment to prompt user when clicking Intent link in private browsing. r=sebastian

Note that the DialogFragment is currently unused and will be used in the
followup changesets.
Comment on attachment 8662119 [details]
MozReview Request: Bug 1173147 - Prompt user when opening market intent. r=sebastian

Bug 1173147 - Prompt user when opening market intent. r=sebastian
Bug 1173147 - Show prompt for GeckoAppShell.openUriExternal. r=sebastian
Attachment #8665179 - Flags: review?(s.kaspari)
Bug 1173147 - Explicitly show Android chooser when there is more than one intent URI match in pb. r=sebastian

After this changeset series, the expected flow for web links is:
  * If not pb, open the Intent URI
  * If pb and no matching applications, open about:neterror
  * If pb and one matching application, show this dialog
  * If pb and > 1 matching application, show the Android system chooser

When the user explicitly chooses to share (and thus should infer they're
exiting Private Browsing), we don't show the dialog.

Custom URIs sort of work: I tested `mailto` and it worked as expected but `tel`
does not work as expected (i.e. it doesn't show the dialog). Perhaps there's an
explicit "Open dialer" code path. To figure this out, I tested this patch
against my Intent URI test page [1].

Decisions around explicitly showing the Android chooser:
When there are multiple application matches to an Intent URI, we
want to show the Android Intent Chooser. However, we have no way
of distinguishing regular tabs from private tabs to the chooser.
Thus, if a user chooses "Always" in regular browsing mode, the
chooser will not be shown and the URL will be opened. Therefore we
explicitly show the chooser (which notably does not have an "Always"
option).

[1]: https://people.mozilla.org/~mcomella/test/uri.html
Attachment #8665180 - Flags: review?(s.kaspari)
Comment on attachment 8665179 [details]
MozReview Request: Bug 1173147 - Show prompt for GeckoAppShell.openUriExternal. r=sebastian

https://reviewboard.mozilla.org/r/20151/#review18131

::: mobile/android/base/ActivityHandlerHelper.java:40
(Diff revision 1)
> +            Log.w(logtag, "Activity not found.", e);

Do we need to pass a logtag? Logging the exception will give us a stack trace.

::: mobile/android/base/GeckoAppShell.java:1085
(Diff revision 1)
> -            Log.w(LOGTAG, "Forbidden to launch activity.", e);
> +            final FragmentActivity fragmentActivity = (FragmentActivity) getGeckoInterface().getActivity();

Uh, hacky. But I can't come up with something simple and nicer either. :)
Attachment #8665179 - Flags: review?(s.kaspari) → review+
Comment on attachment 8665180 [details]
MozReview Request: Bug 1173147 - Explicitly show Android chooser when there is more than one intent URI match in pb. r=sebastian

https://reviewboard.mozilla.org/r/20153/#review18133

::: mobile/android/base/widget/ExternalIntentDuringPrivateBrowsingPromptFragment.java:88
(Diff revision 1)
> +                    context.getResources().getString(R.string.intent_uri_private_browsing_multiple_match_title);

NIT: You can call getString() on a fragment.
Attachment #8665180 - Flags: review?(s.kaspari) → review+
https://reviewboard.mozilla.org/r/20153/#review18133

> NIT: You can call getString() on a fragment.

This method is `static`, but I fixed it above.
Spoke w/ barbara & margaret via email – this & the depending bug are complex w/ a large potential for fallout and it's not high priority enough to deal with the uplift overhead: moving to 44.
tracking-fennec: 43+ → 44+
https://hg.mozilla.org/integration/fx-team/rev/2aea208159a037653861256f1010634624978052
Bug 1173147 - Add Intent in private browsing prompt string. r=sebastian

https://hg.mozilla.org/integration/fx-team/rev/efaebc9afa784e0ddab3e24639bb2fb29a5c18cc
Bug 1173147 - Add DialogFragment to prompt user when clicking Intent link in private browsing. r=sebastian

https://hg.mozilla.org/integration/fx-team/rev/97f244a13ff0552512e25082b6ba9c0b7df8d79e
Bug 1173147 - Prompt user when opening market intent. r=sebastian

https://hg.mozilla.org/integration/fx-team/rev/25c51acbaffa7458d05de52ed3a819566a7523ec
Bug 1173147 - Show prompt for GeckoAppShell.openUriExternal. r=sebastian

https://hg.mozilla.org/integration/fx-team/rev/b216784e5774788a35e771b7b2dc8c048b09545d
Bug 1173147 - Explicitly show Android chooser when there is more than one intent URI match in pb. r=sebastian
https://hg.mozilla.org/integration/fx-team/rev/494ff0d7f3bbd4573372864b9f2c70c6cf8d22e8
Bug 1173147 - Add Intent in private browsing prompt string. r=sebastian

https://hg.mozilla.org/integration/fx-team/rev/a43a907c02fe32724322bf907e4ff4136e364ea4
Bug 1173147 - Add DialogFragment to prompt user when clicking Intent link in private browsing. r=sebastian

https://hg.mozilla.org/integration/fx-team/rev/5a4df2457628c2fc41385dcca653e05eb8f5caa1
Bug 1173147 - Prompt user when opening market intent. r=sebastian

https://hg.mozilla.org/integration/fx-team/rev/afd881fc08a25c38a57343434ba58becb836ffa0
Bug 1173147 - Show prompt for GeckoAppShell.openUriExternal. r=sebastian

https://hg.mozilla.org/integration/fx-team/rev/e0db94364c19e09a6bb8ac8a8b2c3ca49c97e0c0
Bug 1173147 - Explicitly show Android chooser when there is more than one intent URI match in pb. r=sebastian
https://hg.mozilla.org/integration/fx-team/rev/d842dddebda97b023c278dbbd6e1c0683d0d0d1c
Bug 1173147 - Add Intent in private browsing prompt string. r=sebastian

https://hg.mozilla.org/integration/fx-team/rev/b279a769b533c772f084c8c0e1b1166c795db642
Bug 1173147 - Add DialogFragment to prompt user when clicking Intent link in private browsing. r=sebastian

https://hg.mozilla.org/integration/fx-team/rev/a3891c6b14abc26d19f3ad573d8c933f8f96fc83
Bug 1173147 - Prompt user when opening market intent. r=sebastian

https://hg.mozilla.org/integration/fx-team/rev/806d80510c213a12f95c9110be0cf44e16661cee
Bug 1173147 - Show prompt for GeckoAppShell.openUriExternal. r=sebastian

https://hg.mozilla.org/integration/fx-team/rev/efea2819c5bc07fdafa534e27131cc02a9575bd5
Bug 1173147 - Explicitly show Android chooser when there is more than one intent URI match in pb. r=sebastian
Flags: needinfo?(michael.l.comella)
We need appcompat-v7 for DialogFragment.
Depends on: 1208576
Depends on: 1216627
Depends on: 1216629
I can't seem to find this in the Beta 44 rel notes, can/should we add it?
Flags: needinfo?(rkothari)
(In reply to Barbara Bermes [:barbara] from comment #57)
> I can't seem to find this in the Beta 44 rel notes, can/should we add it?

I see this listed as the first item here:
https://www-dev.allizom.org/en-US/firefox/android/44.0beta/releasenotes/
You are right, I was going by the word document which I noticed now only includes additional items which have not been listed on the rel notes websites.

My mistake. Sorry
Whiteboard: forced de-privatization → [adv-main44-]forced de-privatization
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.