Tested this issue on Windows-10 using chrome latest stable #59.0.3071.115 and latest canary #62.0.3168.0 by following steps mentioned below.

1. Navigated to link https://jsfiddle.net/m5b9a0g2/
2. Observed a pop up up dialog displays saying : An embedded page on the webpage says: with the above script provided in original comment.
3. Clicked on 'ok' button 8 times
4. Right clicked on webpage--> View page source and observed able to the see the whole page source.

Reporter@ Could you please confirm the above steps is the right way to reproduce this issue? If anything is missing from our end please let us know.

Thanks!

Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

I do not quite understand what you consider a security issue here (but the security team might understand).
Going a step back, though, is the security issue here about view-source:// (which is not web exposed)? Or about an actual web-exposed feature?

 Issue 749891  has been merged into this issue.

This isn't a security bug.

update: https://jsfiddle.net/skhyafdc/

There is 3 minor bugs in this payload.

1. X-Frame-Options header enabled site bypass

https://www.2600.com is XFO header enabled site, which means opening a page in frame or iframe is not allowed. 
Let's give it a try: data:text/html,<iframe src="https://www.2600.com"/></iframe>

http://savanttools.com/test-frame/https://www.2600.com

Indeed this will show up a blank frame. However, I used html entities in order to execute JavaScript in https://www.2600.com and bypass X-Frame-Options check.

https://jsfiddle.net/skhyafdc/

This shows that JavaScript is executing in https://www.2600.com, which is X-Frame-Options header enforced site.

2. XSS Auditor bypass

I already know that browser Cross-site scripting filter bypass is not considered as a security vulnerability.

Specifically, in multi-line scenario you can bypass Chrome's XSS Auditor. (There are lot's of ways to bypass browser XSS filters, however I've used this condition for this example so I'm not going to cover other bypasses now)

Multiple reflections is not working due to an unclosed quote or the fact that the auditor trusts local resources that are passed without parameters. It is possible because the auditor sees a request with some html tags that look harmless on their own, but can be malicious if they occur more than once. This is usually achieved with script tags.

A simple example where this would work is like:

<a href="payload">payload</a>

As you can see, the payload is reflected two times in the same line. So you can do something like this: \">"</script><script>alert(document.domain)*"\

But this isn’t a common case, usually they are often separated with newlines and other tags like this example: http://wikipedia.fr/Resultats.php?lang=

This time we can use backtick to use ECMA Script 6 Template strings, like this:
 
"/>`;prompt`${document.cookie}`</script><script>`

http://wikipedia.fr/Resultats.php?lang="/>`;prompt`${document.domain}`</script><script>`

This will prompt the domain name. No user interaction and without using parentheses.

The backtick makes it work in a multiline scenario.

The reason this is possible is because the auditor only searches for the same dangerous string in the request and response body, trusts local resources, doesn’t consider multi-injections and is not really strict to avoid false positives, which is important for a browser.

3. page doesn't reload after the content is changed in data: attribute

https://jsfiddle.net/skhyafdc/

After executing JavaScript in https://www.2600.com, you will see that page is changed to #2600. However when we View frame source, the URL bar shows view-source:data:text/html,# and the page content # while it should show the whole source. This means after the page inside an Iframe is reloaded from data:text/html,# to another Iframe, due to empty string 'location.hash="";' the page remains to data:text/html,# while executing JavaScript in https://www.2600.com.   
 

www.2600.com sends a X-Frame-Options header in its home page, but not in the URL to which your original JSFiddle goes (https://www.2600.com/phones//newindex.khtml), so that is not a Chrome issue. This looks like a simple cross site scripting vulnerability of the website (it would be great if you could contact them).
Regarding the data URL not reloading when you change it, it is due to the hash sign, just like any other URL does not reload when you replace anything after the hash sign.

Able to reproduce this issue on Ubuntu 14.04, Windows-10 and Mac OS 10.12.5 using chrome latest stable #60.0.3112.78 by following test case provided in comment #9. By clicking on view frame source from the test case page observed only # is shown.

This issue is seen on older version of chrome M35-35.0.1849.0 as well, Hence removing the bisect label and marking it as untriaged.

I think the only issue here is that anything after the hash sign (#) in a data URL gets appended to the document and rendered instead of being treated as a hash component.
There is already an issue for that bug, so this is a duplicate of it.

Holler if you disagree and provide a reason.