Google Chrome blocks successive invocation of custom URI scheme
Reported by
s.pa...@gmail.com,
Aug 31
|
|||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Steps to reproduce the problem:
I have a need to invoke multiple custom URI scheme (protocol handlers) with on user interaction (e.g. click).
To make it super easy to reproduce, take a look at this code snippet:
<!DOCTYPE html>
<html>
<head>
<script>
function MailToOne() {
iframe1 = document.createElement('iframe');
iframe1.src = 'mailto://1';
document.body.appendChild(iframe1);
}
function MailToTwo() {
iframe2 = document.createElement('iframe');
iframe2.src = 'mailto://2';
document.body.appendChild(iframe2);
}
function MailToOneAndTwo() {
MailToOne();
MailToTwo();
}
function MailToOneAndTwoWithDelay() {
MailToOne();
window.setTimeout(MailToTwo, 3000)
}
</script>
</head>
<body>
<button onclick="MailToOne()">Mail To 1</button>
<button onclick="MailToTwo()">Mail To 2</button>
<button onclick="MailToOneAndTwo()">Mail to 1 and 2</button>
<button onclick="MailToOneAndTwoWithDelay()">Mail to 1 and 2 with delay</button>
</body>
</html>
(you can just copy&paste and run in a browser).
1. Click on 'Mail To 1'
2. Click on 'Mail To 2'
3. Click on 'Mail to 1 and 2'
4. Click on 'Mail to 1 and 2 with delay'
What is the expected behavior?
1. I expect a mail app to open with send to '1' prefilled for me.
2. I expect a mail app to open with send to '2' prefilled for me.
3. I expect a mail app to open with send to '1' prefilled and a mail app to open again with send to '2' prefilled.
4. same as #3.
What went wrong?
1. went ok
2. went ok
3. Only the mail to 1 is invoked.
4. Only the mail to 1 is invoked.
Try on IE11, work as expected.
Similar problem was reported in the following links. Nothing works so far.
https://productforums.google.com/forum/#!topic/chrome/VWSj6NtXJH8
https://stackoverflow.com/questions/28774487/chrome-opens-custom-uri-only-once
https://stackoverflow.com/questions/29789503/strange-behaviour-in-chrome-using-uri-scheme
https://stackoverflow.com/questions/9472703/send-multiple-application-protocols-requests-similar-to-mailto
Some claimed that this is a security measure of Chrome to prevent one-click to perform more than one protocol handler invocation. If this is true or by design, I want to get that confirmation from the Chromium team. And maybe the team would consider to change that behavior.
Did this work before? Yes before ~46
Chrome version: 68.0.3440.106 Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version:
,
Sep 3
,
Sep 3
Tested the issue on chrome reported version# 68.0.3440.106 using Windows-7 with steps mentioned below: 1) Launched chrome reported version, created '.html' file with data provided in comment# 0, dragged and dropped the file into the browser 2) Clicked on 'Mail to 1' button, able to see instance generated on the web-page and pop-up showing the mail app 3) Clicked on 'Mail to 2' button, able to see instance generated on the web-page and pop-up showing the mail app 4) Clicked on 'Mail to 1 and 2' button, able to see two instances generated on the web-page and pop-up showing the mail app 5) Clicked on 'Mail to 1 and 2 with delay' button, able to see first instance generated quickly and second with some delay on the web-page and pop-up showing the mail app @Reporter: Please find the attached screencast for your reference and provide your feedback on it which helps us in further triaging the issue in better way. Thanks!
,
Sep 3
Thank you all for your quick response. @viswa: what I expect when clicking on 'Mail to 1 and 2' button is that, in your case, Outlook is then opened two times. (Please ignore the iframes). Rationale: let's imagine, if the custom uri scheme is not mailto:// but notepad or other desktop applications, I want to be able to invoke such a desktop application twice (or more) with one click.
,
Sep 3
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 4
Able to reproduce the issue on chrome reported version# 68.0.3440.106 and on latest chrome# 71.0.3541.0 using Mac 10.12.6, Ubuntu 17.10 and Windows-10 with the data provided in comment# 0. As this issue is seen from M-60(60.0.3112.0), hence considering this issue as Non-Regression and marking it as Untriaged. Thanks!
,
Sep 4
Thank you, Viswa, for the investigation. I understand that now: - it is accepted that this is a bug, correct? - it is marked as ‘Untriaged’, meaning lower in priority? Will it ever get fixed at all? When approx? - what is the reason to conclude that the issue is seen from M-60? - Why found in M-60 does make this issue a regression? Say we didn’t have this issue in 59, we do in 60. Isn’t that a regression? It was simply not reported before... but a lot of people experienced it as you can see in the links in provided in comment #0. Sorry for asking so many questions. I just want to get it clear. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by viswa.karala@chromium.org
, Sep 2