Chrome Version: 57.0.2979.0 (Developer Build) (32-bit)

What steps will reproduce the problem?

(1) Access a webserver that redirects you (potentially multiple times) to a final URL with a nonstandard URI scheme
(2) Observe that an xdg-open popup appears (like the one in the screenshot)
(3) Try and determine what URL is about to be locally launched

As seen in the screenshot, I only know that xdg-open is about to be run. I'm not sure if this is because this functionality was just recently redesigned and hasn't been finished yet, or if I'm missing OS-level metadata that Chrome would use to figure out the application to launch (I'm not running Ubuntu or similar, FWIW; I'm on Slackware 14.1).

If initial repro testing doesn't match what I see here, I would request this issue not be immediately closed so I can do some further digging.

What is the expected result?

I'd expect to know the URL I'm about to pass to the local application.


What happens instead?

I'm no longer being told what URL is generating the launch, which was the key piece of information that helped me know what was going on.

Also, on my system, I'm only being told xdg-open is about to be launched. I'm not given any further info. Also, the dialog only references "xdg-open" - if I had more than one of these scripts on my system (not uncommon), I wouldn't know which one was going to be used.


Please provide any additional information below. Attach a screenshot
and backtrace if possible.

Chrome used to display an "External Protocol Request" dialog box when I clicked on links with nonstandard URI schemes. This seems to have been replaced with the now very minimalistic dialog shown in the screenshot.

I'm guessing that people got confused and thought they were being hacked or something; that makes sense. However, if the text is going to be hidden, there does need to be a way to re-show it in appropriate circumstances.

In particular, while Windows and macOS might hold up to a minimalist solution like this, the Linux desktop is far too immature to sanely support this approach at this point IMO. I've honestly never actually used (needed) xdg-open, so I have no idea what it would open for a given scheme. I've relied ENTIRELY on the URL to know what something was trying to launch.

So, that's that point. Now let me explain the interesting twist that motivated me to file this issue.

I was middle-clicking search hits from Google earlier and noticed that one of the tabs immediately started flashing. I focused it, which is when I saw (exactly) what you see in the screenshot. Note that the active URL is a Google redirect (on a side note, I think the redirect-handling logic that sometimes hides the final URL could do with some tweaking). I had no idea which of the bunch of middle-clicks I'd just done had opened this tab, so I grabbed the URL and ran it through curl to get the information I needed (which Chrome used to display right on the screen).

Turned out it was a bunch of redirects through what appears to be a broken spam/badly-done SEO website. I'm preserving the redirect chain for posterity:

- https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=52&ved=0ahUKEwjZ6JPNqv_RAhXIppQKHZXSDccQFgj9ATAz&url=http%3A%2F%2Fmostusedtagsinsocial.com%2FFireLark.aspx&usg=AFQjCNEWXGYDn5nLNMe2Ga5XeAmxv2Rw1g&sig2=KdJCgWEZB20K_hTx7rLw0Q -> 200 OK (Javascript+meta-refresh redirect)
- http://mostusedtagsinsocial.com/FireLark.aspx -> 302: http://www.minimumdomain.com/FireLark
- http://www.minimumdomain.com/FireLark -> 302: /youtube.com
- http://www.minimumdomain.com/youtube.com -> 302: apple.comz:windows.com
- http://www.minimumdomain.com/apple.comz:windows.com -> 400 Bad Request

As you might be able to guess, while curl assumed the 2nd-last redirect was a badly-formatted path, Chrome treated it as a local application launch request.

This situation is interesting: I hadn't actually clicked any sort of "launch local application" button; I fell through to this state due to a misconfigured website. The only way I see to fix things for this edge-case is to make it possible to show the URL text.

Here's a simple way to play with this in Chrome if you have socat (same package name) installed:

  socat tcp-listen:8000,reuseaddr,fork exec:'echo -ne "HTTP/1.1 302 Found\r\nConnection: close\r\nLocation: apple.comz:windows.com\r\n\r\n"'

(Then open localhost:8000.) This opens prompts like the one in the screenshot instantly for me.

Note that the string is not magic; things like "test:ohi" work the same way too. It just has to be nonstandard so Chrome treats it as an application launch request, and if Chrome does its own installed-application analysis (? I have no idea), the URI scheme may need to be different from those already registered.
 

Deleted: 2017-02-08-122133_1024x768_scrot.png 34.3 KB

	2017-02-08-122133_1024x768_scrot.png 34.3 KB View Download