1173147 - Prompt the user when opening intent URIs in private browsing mode

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: (sample) Galaxy S5 Messages external link warning

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.

Comment 1

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

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.

Comment 2

[Wesley Johnston (:wesj)]

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.

Comment 3

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(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

Comment 4

[Wesley Johnston (:wesj)]

(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"

Comment 5

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

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 :)

Comment 6

[Matej Novak [: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?

Comment 7

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

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?

Comment 8

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(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?

Comment 9

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

(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"

Comment 10

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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.

Comment 12

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Moving tracking flag from Bug 1186423.

Comment 14

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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.

Comment 15

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: 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 16

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: 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 17

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: MozReview Request: Bug 1173147 - Prompt user when opening market intent. r=sebastian

Bug 1173147 - Prompt user when opening market intent. r=sebastian

Comment 18

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

This changeset series is incomplete: we still need to fire the DialogFragment when clicking arbitrary links (which is much messier).

Comment 19

[Sebastian Kaspari (:sebastian; :pocmo)]

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?

Comment 20

[Sebastian Kaspari (:sebastian; :pocmo)]

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 21

[Sebastian Kaspari (:sebastian; :pocmo)]

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().

Comment 22

[Sebastian Kaspari (:sebastian; :pocmo)]

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?

Comment 23

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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

Comment 24

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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 25

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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 26

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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

Comment 27

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(Still need to get random links from web content working)

Comment 28

[Sebastian Kaspari (:sebastian; :pocmo)]

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.

Comment 29

[Sebastian Kaspari (:sebastian; :pocmo)]

Comment on attachment 8662119 [details]
MozReview Request: Bug 1173147 - Prompt user when opening market intent. r=sebastian

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

Comment 30

[Daniel Veditz [:dveditz]]

(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.

Comment 31

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

NI self to respond to comment 30 on Monday.

Comment 32

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(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).

Comment 33

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: 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

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.

Comment 34

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

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.

Comment 35

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: Explicit android chooser dialog

Comment 36

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

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?

Comment 37

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(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?"

Comment 38

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: Explicit android chooser dialog v3

Comment 39

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

Comment on attachment 8665140 [details]
Explicit android chooser dialog v3

WFM!

Comment 40

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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 41

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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 42

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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

Comment 43

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: MozReview Request: Bug 1173147 - Show prompt for GeckoAppShell.openUriExternal. r=sebastian

Bug 1173147 - Show prompt for GeckoAppShell.openUriExternal. r=sebastian

Comment 44

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: MozReview Request: Bug 1173147 - Explicitly show Android chooser when there is more than one intent URI match in pb. r=sebastian

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

Comment 45

[Sebastian Kaspari (:sebastian; :pocmo)]

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. :)

Comment 46

[Sebastian Kaspari (:sebastian; :pocmo)]

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.

Comment 47

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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

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

This method is `static`, but I fixed it above.

Comment 48

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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.

Comment 49

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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

Comment 50

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Backed out because I have to back out bug 1201206: https://hg.mozilla.org/integration/fx-team/rev/3bbea41152bc

Comment 51

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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

Comment 52

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Backed out because I had to back out bug 1201206: https://hg.mozilla.org/integration/fx-team/rev/9d8432afaf64

Comment 53

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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

Comment 54

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/d842dddebda9
https://hg.mozilla.org/mozilla-central/rev/b279a769b533
https://hg.mozilla.org/mozilla-central/rev/a3891c6b14ab
https://hg.mozilla.org/mozilla-central/rev/806d80510c21
https://hg.mozilla.org/mozilla-central/rev/efea2819c5bc

Comment 55

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

We need appcompat-v7 for DialogFragment.

Comment 56

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Added to FF44 release notes.

Comment 57

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

I can't seem to find this in the Beta 44 rel notes, can/should we add it?

Comment 58

[:Margaret Leibovic]

(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/

Comment 59

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

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