New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 663325 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug-Regression



Sign in to add a comment

CSP with "child-src *" refuses "mailto:" in iframes

Reported by michisch...@gmail.com, Nov 8 2016

Issue description

Chrome Version: 54.0.2840.71
Other browsers tested:
     Chrome: Ok, 53.0.2785.143
    Firefox: OK, 46.0.1
         IE: OK, 11.0.9600.18499

What steps will reproduce the problem?
(1) Open the attached "mailto-csp.html"
(2) Click on the second list element (mailto:test@test.com)
(3) Open Console: Refused to frame 'mailto:test@test.com' because it violates the following Content Security Policy directive: "child-src *".

What is the expected result?
- Up until Chrome 54 the default email composer was opened by the OS.
- "child-src *" should allow everything inside the iframe

Note:
A "mailto:"-link in an iframe seems a bit strange. But this was the best solution for opening a "mailto:"-link programmatically.
You could also open a new window with the "mailto:"-link as href, but this leads to a new window which will get opened and closed instantly (flickering).
You could also use window.location.href = "mailto:test@test.com", but this fires a onbeforeunload-event which could break running scripts and/or long-polling requests.
Embedding an invisible iframe with the mailto-link was working just fine in all tested browsers.

What happens instead?
The "mailto:"-link gets refused by CSP.

Additional information
- about:blank seems to work
- I've found no change note or similar which would describe this change in behavior
- http://stackoverflow.com/questions/9740510/mailto-link-in-chrome-is-triggering-window-onbeforeunload-can-i-prevent-this
 
mailto-csp.html
566 bytes View Download
Cc: jmukthavaram@chromium.org
Labels: Needs-Feedback
Tested this issue on Windows 7 as per steps in comment#0 & observed below error in latest stable-54.0.2840.99 & latest canary -56.0.2915.0.

" Refused to frame 'mailto:test@test.com' because it violates the following Content Security Policy directive: "child-src *". "

Verified in 54.0.2819.0 and observed no error in devtools-> console.

Please find the attached screen cast & confirm the above observation is the expected behaviour? if no, please provide us the same.

So that we can triage the issue further.

Thanks.
663325.mp4
366 KB View Download
I’ve tried to download Chrome 54.0.2819.0, but couldn’t find the corresponding installer on  https://commondatastorage.googleapis.com/chromium-browser-continuous/index.html (https://omahaproxy.appspot.com/ tells me that 409769 is the "Branch Base Position"  for version 54.0.2819.0).
So how can I download Chrome 54.0.2819.0 to verify your observations?

The expected behavior is, that the "mailto:"-link doesn’t get refused by CSP and therefore "loaded" inside the iframe. (The "mailto:"-link doesn’t actually get loaded, but the OS will open the default e-mail client and initiate a new mail composer.)
Clicking the list item should trigger the same action as when I enter "mailto:test@test.com" in the address bar of chrome. (Note: Maybe there is no  default e-mail client on your test machine. On Windows 7: Try setting a mail client in Control Panel - All Control Panel Items - Default Programs or try downloading an e-mail client like Thunderbird or Windows Live Mail)
But yes, your screencast "663325.mp4" demonstrates that 54.0.2819 wasn’t affected by this issue.
Components: Blink>HTML>IFrame
Labels: -Type-Bug -Needs-Feedback M-56 OS-Linux OS-Mac OS-Windows Type-Bug-Regression
Owner: asargent@chromium.org
Status: Assigned (was: Unconfirmed)
Thanks for the Feedback.This is regressed in M 54 and seen on Mac 10.11.6, Win 10 and Ubuntu 14.04 using stable 54.0.2840.98/99/100 and canary 56.0.2918.0.

Bisect info:
Good: 54.0.2819.0 
Bad : 54.0.2820.0 

Unable to get the tool suspect as always getting good even if increased the Bad revisions.
OMahaproxy UI CL :
https://chromium.googlesource.com/chromium/src/+log/54.0.2819.0..54.0.2820.0?pretty=fuller&n=10000
Possible suspect from above : Review-Url: https://codereview.chromium.org/2208483002
asargent@ : Could you please take a look into this if its related to your change.Else could you please assign to an appropriate owner for the same.
Ping asargent, PTAL.
Owner: rdevlin....@chromium.org
I'm no longer working on chrome, so punting over to Devlin for triage. 

Components: Blink>SecurityFeature
Owner: mkwst@chromium.org
(Looking through old bugs)

This still reproduces on Chrome stable, and does seem unexpected to me.  Over to mkwst@ for CSP triage.

Comment 8 by mkwst@chromium.org, Jun 20 2018

Owner: andypaicu@chromium.org
And I'll punt it to Andy. :)

Sign in to add a comment