Ah yeah not a favorite for people. This came up a couple months back w/egm.

Ainslie's thoughts at the time:
If it's an "action" thing - it can live on the toolbar.
If it's an origin specific setting - it should live in pageInfo. 
This gets kind of messy for passwords and translate, which could be thought of as per-origin settings. 
 
Handler seems like a good candidate for pageinfo but ... I wouldn't want to start prompting for it if sites just request onload without user gesture. Maybe we need a state for the pageinfo access point that means "something is new here, wants your attention" that we could use for ignored permissions prompts and for this handler case. (See attached image)

The handler does feel like it should be treated like other permissions. My thought was that we should consider bringing back glen's originally proposed UI distinction between onLoad and onUserGesture prompt UIs. Since that seems like a nice property of today's handler UI in the omnibox. 

---

+ dominickn@ is starting an effort to audit page actions so I'd say that would likely be bundled under that. (Feel free to own it if you wish - or dupe if that's more helpful.)

Deleted: PageIconAlert.png 14.5 KB

	PageIconAlert.png 14.5 KB View Download

FYI it seems my attachment didn't upload, so trying again

Deleted: Screen Shot 2016-04-08 at 12.56.45 AM.png 148 KB

	Screen Shot 2016-04-08 at 12.56.45 AM.png 148 KB View Download

I'm not sure what we should do in the long run, but even if we keep the prompt style as it is today I think we can go a really long way just by revising the copy.

Previous discussion on this:  https://crbug.com/333813 

Ainslie@ is traveling a bit next week but I'll see him the week after next and will bring this up. Maybe he did update the language, and it just never got on the related bug (thanks, meacer.)

Assigning bug to me in the interim.

Talked with ainslie@. UI Review recently went through this for iOS:
https://groups.google.com/a/google.com/forum/#!topic/chrome-ui-review/YeGCEMgho1A

Dialog decision is to say:
This page will open in another application.
CANCEL   OPEN

Sooooo much shorter! The concept of where external protocol handlers live is still a Jewelbox effort, but we could make this bug specifically about updating the text. No UI needed then, just someone to implement this on desktop. Assigning to emilyschechter to delegate.

 Issue 333813  has been merged into this issue.

re #9: Is the phrase "This page will open in another application" meant to be title text or body text?

Body text (there's no title text in the Bling mock.) Here's the link from the UI Review thread:
https://screenshot.googleplex.com/iX37x5OHp8a

We could come up with something if need-be for other platforms. Perhaps to start "Open app" in homage to Owen's original proposal.

Talked with Dominick, we suspect this is probably orphaned, so he'll include it as part of looking at Jewelbox.

I'm aiming to land this change for M53. It's low hanging fruit - we just have to confirm what strings we want and land them in time.

I've attached a strawman proposal on Mac, ChromeOS, and Linux (I didn't have a Windows box handy). Apologies for the low quality - these are taken remotely so they're all a bit fuzzy, but I want to focus on the copy:

1. What text should the title have?
2. I have removed the name of the application because it can be very long on Windows (full path from C:\ in the worst case). The super long cases make the dialog much more complicated. Is everyone okay with suppressing the name of the application?
3. I've kept the full term "application" to be consistent with what was approved for Bling. Is "app" a more understandable term for users / is it acceptable to UX?
4. Any other comments?

Assigned to rolfe@ for comments on the text.

Deleted: Screen Shot 2016-06-17 at 21.22.46.png 67.6 KB

	Screen Shot 2016-06-17 at 21.22.46.png 67.6 KB View Download

Deleted: Screen Shot 2016-06-17 at 21.17.49.png 37.1 KB

	Screen Shot 2016-06-17 at 21.17.49.png 37.1 KB View Download

Deleted: Screen Shot 2016-06-17 at 21.13.31.png 87.1 KB

	Screen Shot 2016-06-17 at 21.13.31.png 87.1 KB View Download

Is it not possible to truncate the app name on Windows so that we can keep it? Your strawman dialogs are basically "something is going to happen, but I can't tell you what, are you ok with that?"

The user has zero information to make that "Launch Application/Cancel" decision.

They also in your strawman have zero information to make the "Remember my choice" checkbox decision. "all links of this type" = what type? We again aren't saying.

If we remove the app name and the protocol, then this does not appear to me to be a useful dialog any more.

> I have removed the name of the application because it can be very long
> on Windows (full path from C:\ in the worst case)

Then we should truncate it, and/or investigate mapping it to a user-friendly app name.

My modification of your strawman would be:

---
Open application?

This page will open in the "App Store" application.

[ ] Remember my choice for all "appstore:" links
---

+Scotts, win folks

sky, scottmg, can we get a useful user-visible name for an app used in this dialog rather than the whole path?

A human-readable app name would get my vote if we can reliably grab it. I could imagine using it in the title and primary button (instead of the body text as #17 proposes). Another friendliness idea (and one that is more inline with the iOS approach mentioned in #9) is to try removing the always/remember checkbox. 

rolfe@, depending on the answer to #18, could you make a few images to see how a few string variations feel in context?

I'd also be much happier including the app name if we can get a consistent human-readable version. I'm just concerned about examples where an executable is being launched with path arguments, which happens on Windows. I'm not sure using a heuristic to pluck out a .exe would be the best user experience - if we can reliably map to better names that would be perfect.

emilyschechter@ and I originally brainstormed an example with the app name in the title. I've attached an example of what this looks like on Linux (with the checkbox still there and with it removed).

Deleted: Screen Shot 2016-06-20 at 19.52.40.png 67.5 KB

	Screen Shot 2016-06-20 at 19.52.40.png 67.5 KB View Download

Deleted: Screen Shot 2016-06-20 at 20.01.03.png 50.1 KB

	Screen Shot 2016-06-20 at 20.01.03.png 50.1 KB View Download

+1 to app name. Let's try to get a consistent human-readable version on Windows, if we can't, we can at least do it for Linux/Mac (can we do it for iOS too?)

I frankly like using "app" consistently instead of "application"... I think today's mobile first users are much more likely to understand "app". We could run a quick study if people are opposed. I would vote for doing this on iOS as well.

Re: cutting "remember my choice" -- SGTM, that's a good friendliness idea. I wonder if we can remove some of the blank space between the title & buttons in that last mock?

Couple questions!

1) Any way to tell how often people check the "remember my choice" checkbox? Would we ever check it by default (or alternatively, remove it) if the numbers are high/low enough?

2) Curious why we don't copy the Bling text exactly? (Plus on go/uxwordlist "open" is preferred to "launch.") Then it's just a matter of refining based on whether you have a useful app name or not.

A1) Useful
Open [app name]?
This page will open in [app name].
CANCEL   OPEN

B1) Not useful (everything matches Bling except for the title, unique to desktop)
Open another app?
This page will open in another application.
CANCEL   OPEN

Of course THEN I get to thinking we could change the perspective a bit. It does mean straying from the Bling dialog action button.

A2) Useful
Leave Chrome?
This page will open in [app name].
CANCEL   LEAVE

B2) Not useful
Leave Chrome?
This page will open in another application.
CANCEL   LEAVE

I rather like the second set a bit more!

1) I can't find an UMA stat, I doubt we have one. Dom any ideas if we do? If we don't, I would tend to remove it for the sake of friendliness and simplification.

2) LEAVE does seem a bit scarier than OPEN. I also think I'm personally used to seeing "Open in App?" so seeing "LEAVE" feels scary. But that's just one data point.

For all of these dialogues, is the second line really adding anything at all? Can we just use one of those lines?
I.e.

Open [app name] / another app?
CANCEL OPEN

I don't think there's any UMA statistics for this dialog, and I'd rather not wait another two cycles to land a stat and see what it says.

I actually quite like rolfe@'s A2 and B2 suggestions. I've stared at the dialog for a while, and I personally think having a title and a single text line feels more "balanced" (these dialogs are all designed to have at least some text in the box, so they feel empty without it). I don't think Leave is that scary, and it's a very accurate description of what's going on (the analog to mobile, where you do fully leave the app, but it's still there for you to come back to is nice).

Yeah it's a toss-up. Generally we want the title to align with the action button (so "Open" in the title and "Open" in the action button in the event you don't read the blurb, which is probably pretty common.)

I can see how "Leave" might be scarier/more destructive-sounding. It's fine to go with A1/B1 for now (using "application",) and perhaps add a metric to the checkbox and see how many people click on it (then possibly remove it if the data looks good!)

I'm also OK with emilyschecter's proposal to change "application" to "app" across the board as well. If we do it here I can reach out to iOS to change it there as well.

emilyschechter@ reminded me I missed the CrOS one. For that "cannot" is not encouraged (go/uxwordlist again. It has a lot of opinions!) How about:

Unable to open
Chrome can't open this page in another app/application.
[OK]

Although it might be nice to explain a bit more. Like "Application unavailable" in the header, although I presume for CrOS we can't open any maybe? In which case possibly "Unable to open on this device" but that's kind of a downer.

Also curious if it blocks users from opening the link some other way instead of getting stuck. If we know we can't open in another app we could open in the current one and don't show an error (sort of like what we landed on for Chrome on Android: https://groups.google.com/a/google.com/forum/#!topic/chrome-ui-review/6glgzb0tCy8) I don't know if the rules are different for CrOS though.

Thanks Rebecca! Yep, for CrOS we can't open anything else. Not showing anything and instead showing something in DevTools is interesting, and I think all the reasoning in the Chrome-UI-Review thread holds for this case (unless there is some other case for CrOS that I don't know about. I'd be fine with dropping it on the floor, as per the resolution of that thread.

I'm also fine with leaving the checkbox and adding metrics so we can potentially remove it later, but not gating on that now. How about "always open links for [app]"?

So the current proposal is:

A) (if not CrOS, and know name of app)
Open [app name]?
This page will open in [app name].
[] Always open links for [app name].
CANCEL   OPEN

B) (if not CrOS, and dont know name of app)
Open another app?
This page will open in another application.
[] Apways open links for this app.
CANCEL   OPEN

C) (if CrOS)
no UI, drop on floor, DevTools notification

LGTY @rolfe?

Thanks for summarizing. Sounds good to me!

dominickn@ - We can revisit C wording if the no-UI solution is not possible.

Re #18: I don't know without writing code to check, but based on "Control Panel\Programs\Default Programs\Set Associations" having a useful name, I would assume a user-presentable name is in the registry somewhere, we'd just have to dig it out.

+Internals>PlatformIntegration, someone else probably knows more about associations (see #18 and #29).

Can we trust whatever name is registered in the registry? Do we want to trust it?

It's so cool we're finally fixing this!!

About the registry trustworthiness - I'm thinking yes, we'd trust it? Is there a threat model where a bad actor could change that part of the registry and register a scheme handler, but not change the name of the executable to something trustworty sounding?

 Issue 519737  has been merged into this issue.

benwells—

Re the bug dup, are we making this dialog tab-modal in this bug? I thought we were only rewording it here, which would make the other bug not a dup.

The modal thing was only for Mac and Cros. In this bug we're considering dropping it for CrOS, we should just as part of this bug also make it tab modal for Mac.

Dom - can you tab-modalise this dialog on Mac while you're there?

assigning to dominickn@ (but feel free to send it back to me if needed)

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

So the consensus seems to be to find a way to query the registry on Windows to turn what may be an application path into a readable app name. Does this already exist somewhere? I don't have cycles to implement it at this time.

After some investigation (thanks mgiuca@ and benwells@), we've worked out that the registry is only queried for Windows 7 and earlier; Windows 8+ uses a different mechanism that should result in a nice name.

For Windows <=7, the registry gives you a path to the executable, but there doesn't seem to be a standard, commonly used place to store a readable name aside from in the executable's file info. We have methods to query this, but they require an async call to the FILE thread, and that change means messing around with a bunch of things in base (because it will involve changing everything to take a callback etc.).

So I've just extracted the executable name from the registry for the dialog. This isn't perfect (e.g. see the example, which was taken using "telnet" as the protocol), but possibly good enough given that it's Windows <=7 only that will see it. Thoughts?

Deleted: new-protocol-win7.png 9.0 KB

	new-protocol-win7.png 9.0 KB View Download

Deleted: Screen Shot 2016-08-04 at 2.29.47 PM.png 28.5 KB

	Screen Shot 2016-08-04 at 2.29.47 PM.png 28.5 KB View Download

Deleted: Screenshot from 2016-08-04 15:30:57.png 9.0 KB

	Screenshot from 2016-08-04 15:30:57.png 9.0 KB View Download

Deleted: Screenshot from 2016-08-04 15:32:20.png 14.6 KB

	Screenshot from 2016-08-04 15:32:20.png 14.6 KB View Download

I'm a fan.

I still think it should say "Open this link with <title>", not "Open <title>". And we possibly need some warning about security (like what we had before), though certainly not as verbose.

The Windows one is not great if it's going to say "rundll32.exe", since this is just a shim. We should try to do a better job of figuring out what application will actually open, but that can be done in a follow-up. Also I presume Windows 8/10 will be better.

I'll fix the Linux one later; xdg-open has similar issues to rundll32.exe (it is a generic shim).

Re: wording, I gravitate toward c#44's "Open this link with <title>?" over "Open <title>?" In addition, the button titles should be brought in line with whatever the title ends up saying. Right now, for example, the title says "Open this link with SomeApp?" but the confirmation button says "Launch Application" - these are two different things (open link vs. launch app). It might be better to change the title to "Launch <title> to open this link?"

The string changes make sense to me (so many ways to write strings!)

I'm not as sure about the value of a warning (even a short one.) The dialog operates as the warning really (and per Comment 9 most recent thinking from UI Review is no warning is needed, although that iOS dialog may have been in a different context.)

#44: As #46 said, we're following what was approved for iOS (where the dialog is cut to the single line with no warning). I'm faintly against adding a single line warning for the same reason as rolfe@ - I don't think it hurts much, but I also don't feel like it adds much value on top of the fact that we're showing a dialog.

#45: thanks for catching this - I've updated to "app" terminology in the button in the CL implementing this. So far I think the majority of commenters here prefer the shorter title text in #42, but if opinion swings the other way I'm happy to change it.

+1, FWIW -- also don't think an additional warning helps. I tend to prefer the shorter "open app" strings as well, to match with iOS.

Just one more thing about the warning: should this go through security review to make sure it's OK to remove the warning? (I don't like it either, and I don't want to be "warning guy", but just making sure the Security team is OK with this, since the warning does serve as a security mechanism on the boundary between Chrome and unspecified native applications.)

Sorry, Dom pointed out that several of the people making the decision are on Security team. I meant more of a formal security review (i.e., team-wide emails) but if that's sufficient, then great. No argument from me.

I'd like to land this this string update for M54 - crrev.com/2076253002. If there are no further comments by the end of the week I'll go ahead and send for review.

Can we get this landed soon?

This has been held up over feedback from UI review as well as being bumped down my priority list a little bit. Should be on track for M55 though.

Based on feedback from UI review, here is an updated screenshot on Mac, Linux, and ChromeOS. Windows to come since it's an interesting case now.

Deleted: Screen Shot 2016-09-28 at 5.28.42 PM.png 19.5 KB

	Screen Shot 2016-09-28 at 5.28.42 PM.png 19.5 KB View Download

Deleted: Screenshot from 2016-09-22 18:52:27.png 13.8 KB

	Screenshot from 2016-09-22 18:52:27.png 13.8 KB View Download

Deleted: Screenshot from 2016-09-22 10:28:38.png 7.5 KB

	Screenshot from 2016-09-22 10:28:38.png 7.5 KB View Download

I discovered that on Windows 10, you can have a "Pick an application" app name come up if the system doesn't yet have a default handler. Here are screenshots comparing what Chrome currently does, what my patch will do, and what the Pick an Application app looks like when it comes up.

I'm not sure if having a request to open "Pick an application" is all that useful, given that Windows just shows a picker when you open it. The picker app is kind of like the question we ask in the external protocol handler, it's just that our dialog gates whether you leave Chrome, and Pick an Application lets you choose what app to use. Thoughts on this?

Deleted: Current.png 19.5 KB

	Current.png 19.5 KB View Download

Deleted: Capture.PNG 8.4 KB

	Capture.PNG 8.4 KB View Download

Deleted: pick_an_application.png 17.0 KB

	pick_an_application.png 17.0 KB View Download

Has this been solved? 
Now when I try to use an external application it opens a windows telnet client. When I fallow these steps: http://www.daxy.net/2009/08/change-default-telnet-client-in-windows.html and try to change to secureCRT secureCRT returns an error: "The port number supplied was invalid." When the same thing using FireFox its works. Which tells me that the way Chrom sends the information to secureCRT is different. 
Here is the link that I send: telnet://<IP or domain name>:10032

Per No.56 - will leave it others more in the know to answer that!

Per No.55 - CrOS has a similar picker: https://folio.googleplex.com/chrome-ux-specs-and-sources/Cros%20ARC++/Intents/Preview-intents#%2FP-Intents-01-Chrome.png%3Fz=width followed by the dialog and the designer on that (jennschen@) is open to dropping the dialog altogether if that's reasonable. I'm running into a similar issue on dialogs for incognito (e.g. is the picker sufficient?) so what I'm hoping to do is draft the current state of the world and talk with the privacy incognito contact vadym@ tomorrow.

This is in danger of missing M55 as well. Since the changes I've proposed don't actually modify when the prompt appears (just what appears), I'm going to send it to review and land it. If necessary, we can continue making fixes through the testing period or roll back if need be.

That SGTM, Dom, thanks. Is the picker thing the only decision we're missing?

Rebecca and I just discussed 2 items:

(1) Picker. If there's a picker, we shouldn't show the dialog. I don't think this is blocking for m55, but would be nice to merge it in or fix it asap. I added this detail to the mocks.

(2) Win <7 -- Rebecca found a final-looking mock that said "Launch Application", and I just wanted to make sure that wasn't what we're launching. (It could have just been an outdated mock, so just double checking)

AFAIK, the only way we can detect that the picker is launching is hard-coding its executable name, which is kind of a bad solution. Otherwise we'll need to spend some time trying to work out if there's some other more reliable signal we can use.

Here's a super long app name on Linux, just for people to eyeball. I've ellided it to 64 characters - what do people think?

Deleted: Screen Shot 2016-10-05 at 10.51.13.png 152 KB

	Screen Shot 2016-10-05 at 10.51.13.png 152 KB View Download

#61: @Rebecca, do you know someone who might have an idea of how to detect picker?
#62: Can we elide more than that? Seems extremely long. 32 Characters?

32 character ellision attached.

Deleted: Screenshot from 2016-10-05 12:53:30.png 21.8 KB

	Screenshot from 2016-10-05 12:53:30.png 21.8 KB View Download

32 character ellision looks good!

I'm noticing now you don't need the period after the checkbox sentence. Sorry for not catching that earlier. It's not a biggie if it's too late to update.

Per picker detection: I don't know who to go to for Win engineers. rpop@ is out for a couple weeks so I'm not sure of her back-up posse. I'm almost rather hard-code the exception rather than have "Open Pick an application?" appear! How often do executable names change? Maybe we chance it?

I'll emphasise that the current dialog appears before Pick an Application as well, so we wouldn't be regressing right now. I would prefer to not have to deal with that fix for M55 since I'm almost sure we're going to have to fiddle with this while it's in beta.

Oh sorry, I see. Yeah I won't hold you to that one. Just an icky discovery but definitely we'd need to fix it somehow, not necessarily tied to this.

emilyschechter - would this be a separate bug? Maybe rpop@ can assign when an eng is available (although sooner is better, guessing it might take longer than we like.)

I'll make it a separate bug. Thanks all!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0c9a5065a8a7c4b760b79eb996548b1921ed05ea

commit 0c9a5065a8a7c4b760b79eb996548b1921ed05ea
Author: dominickn <dominickn@chromium.org>
Date: Thu Oct 06 20:49:00 2016

Simplify the text in the external protocol confirmation dialog.

The external protocol handler dialog currently presents users with
a very large amount of jargon-filled text. This CL simplifies the dialog
down to just a title containing the app name and the existing checkbox.

On Windows 7 and earlier, the registry is queried for an app path,
which is displayed in the dialog. This CL modifies the query to
retrieve a program name from the app path, falling back to just
the executable name if the retrieval doesn't succeed.

A new histogram to log the number of times users check the
checkbox in the dialog is also added.

BUG= 601725 

Review-Url: https://codereview.chromium.org/2076253002
Cr-Commit-Position: refs/heads/master@{#423664}

[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/app/chromium_strings.grd
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/app/generated_resources.grd
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/app/google_chrome_strings.grd
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/chromeos/external_protocol_dialog.cc
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/external_protocol/external_protocol_handler.cc
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/external_protocol/external_protocol_handler.h
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/shell_integration_win.cc
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/ui/cocoa/external_protocol_dialog.mm
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/ui/external_protocol_dialog_delegate.cc
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/ui/external_protocol_dialog_delegate.h
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/ui/protocol_dialog_delegate.h
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/ui/views/external_protocol_dialog.cc
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/tools/metrics/histograms/histograms.xml

Hey Dom, would you be able to add:

(1) test instructions for triggering 
(2) doc with screenshots across platforms (or I can do this, with triggering instructions, whatever's easiest)

This will make ui-review and manual testing easy :)

You can test this by going to http://dominickng.com/chromium-demos/security/external-protocol/click-to-launch.html and clicking the various links on different platforms. In my testing, I've found the trigger to work on:

 - Mac: use the "call" link
 - Windows: use the "telnet" link
 - Linux: use the "mail" link
 - ChromeOS: use the "Skype" link

If the links I've specified above don't work, try a different one on the page (it'll depend on what your setup is).

I think there are screenshots across all platforms in this bug already.

Verified the issue on windows 10, Ubuntu 14.04 and Mac 10.11.6 using chrome dev version #55.0.2883.6 as per the comment #0, #14 and #71

Observed that the fix is working as expected.

Attaching screenshots for reference

Hence, adding the verified labels.

Deleted: 601725@MAC.png 193 KB

	601725@MAC.png 193 KB View Download

Deleted: 601725@Windows10.PNG 35.2 KB

	601725@Windows10.PNG 35.2 KB View Download

Deleted: 601725@Linux.png 169 KB

	601725@Linux.png 169 KB View Download

Re: c#72, thanks, could you flip the test bit in Issue 649542?

Note that we still need screenshots for Linux and ChromeOS (mail didn't look like it triggered the Linux dialog). I'll work on triggering and attaching.

Dom - I tested on CrOS Dev 55.0.2878.0 and got the old dialog. Is that WAI?

Same with Linux 55.0.2882.0 dev -- seeing the old dialog (tested w "click to call")

This change is first present in 55.0.2883.0, so that's why you haven't seen it yet. CrOS dev is often quite slow, but it should roll to Linux dev in the next day or two.

Awesome, thanks! Could you please note the comments in this bug that show the current screenshots for Linux and CrOS? (And if no current screenshot, add one?) This would be super helpful to start ui-review.

Screenshots for ChromeOS and Linux attached.

Deleted: Screenshot from 2016-10-12 13:18:04.png 4.9 KB

	Screenshot from 2016-10-12 13:18:04.png 4.9 KB View Download

Deleted: Screenshot from 2016-10-12 13:19:40.png 10.2 KB

	Screenshot from 2016-10-12 13:19:40.png 10.2 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0c9a5065a8a7c4b760b79eb996548b1921ed05ea

commit 0c9a5065a8a7c4b760b79eb996548b1921ed05ea
Author: dominickn <dominickn@chromium.org>
Date: Thu Oct 06 20:49:00 2016

Simplify the text in the external protocol confirmation dialog.

The external protocol handler dialog currently presents users with
a very large amount of jargon-filled text. This CL simplifies the dialog
down to just a title containing the app name and the existing checkbox.

On Windows 7 and earlier, the registry is queried for an app path,
which is displayed in the dialog. This CL modifies the query to
retrieve a program name from the app path, falling back to just
the executable name if the retrieval doesn't succeed.

A new histogram to log the number of times users check the
checkbox in the dialog is also added.

BUG= 601725 

Review-Url: https://codereview.chromium.org/2076253002
Cr-Commit-Position: refs/heads/master@{#423664}

[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/app/chromium_strings.grd
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/app/generated_resources.grd
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/app/google_chrome_strings.grd
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/chromeos/external_protocol_dialog.cc
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/external_protocol/external_protocol_handler.cc
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/external_protocol/external_protocol_handler.h
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/shell_integration_win.cc
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/ui/cocoa/external_protocol_dialog.mm
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/ui/external_protocol_dialog_delegate.cc
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/ui/external_protocol_dialog_delegate.h
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/ui/protocol_dialog_delegate.h
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/chrome/browser/ui/views/external_protocol_dialog.cc
[modify] https://crrev.com/0c9a5065a8a7c4b760b79eb996548b1921ed05ea/tools/metrics/histograms/histograms.xml

[Automated comment] removing mislabelled merge-merged-2840

Are we doing anything to help users restore the ability to open other apps if they previously answered "do nothing" and to remember the choice? Right now they are locked out. 

Should I file a separate bug for that?

That's a separate issue, we should discuss that piece in  Issue 62799 .

 Issue 161492  is blocked by  Issue 333813  which was merged into this one.
It appears with this change there is no way to get the URL at all, not even visually.

#85: That's correct. It was determined that the user's trust decision should be predicated on the app that is to be opened rather than on the URL (as the URL is usually less informative and typically long and scary for most users).

 Issue 524550  has been merged into this issue.