@kleppe - Thanks for posting the issue.
Google Chrome doesn't support iframes, instead webview tags can be used.
Please refer the following URL for more information - https://developer.chrome.com/apps/app_external.

Thanks.

What do you mean by "Chrone does not support iframes"?

The webview tag is not an option here, as it is only available in web or mobile apps. Blobs should also work for sandboxed iframes.

Please see the examples above.

Thank you for providing more feedback. Adding requester "pnangunoori@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

Tested on Chrome Stable #59.0.3071.115 , Canary # 61.0.3143.0 mentioned issue is reproducible on Mac 10.12.5, Ubuntu 14.04 and Windows 10. 

Untriaging this issue as different behavior is noticed on different versions of Chrome.

Observations: 
1. Till Chrome #50.0.2624.0 behavior is similar as mentioned in the bug.
2. In the builds before #49.0.2565.0, Both the links provided are not getting played.

@kleppe - apologies for the miscommunication and thanks for the patience.

Thanks.

WDYT? Artur

After discussion with Artur:

It seems the question here is whether an opaque-origin should match itself. The blob was created with an opaque-origin and it seems it does not match the sandboxed iframe's opaque-origin. There are two possibilities and I'm not sure which is correct:

1) The blob origin should not match the iframe origin. If that is the case I think this is a spec issue if I interpret the same origin algorithm correctly (https://html.spec.whatwg.org/multipage/origin.html).
2) The blob origin should match the iframe origin. If that is the case we have an implementation issue.

mkwst@, jochen@ - WDYT?

An opaque origin should match itself (step 1 of https://html.spec.whatwg.org/#same-origin).

Blobs ought to be same-origin with the document that created them, but we don't have a good way of doing that today, as we parse the origin out of the blob URL's path: https://url.spec.whatwg.org/#origin. Since opaque origins serialize to `null`, that's all we've got to work with, and we can't distinguish between the specific opaque origin for the page and the opaque origin for the blob. We fail closed by treating them as distinct.

The File API spec updates URL's algorithm to keep a blob registry, which would allow us to fix this reasonably. There's some ongoing discussion in https://github.com/whatwg/url/issues/127.

mek@: Is there a bug we should dupe this against?

Assigning to mek@ to get it out of the triage queue. :)

re #9, we do keep a blob origin registry (currently in PublicURLManager.cpp, a thread specific BlobURLOriginMap, used by SecurityOrigin::Create(KURL)), which is supposed to address this usecase. And furthermore we do have WPT tests that verify that yes, loading a same-unique-origin blob URL works (https://w3c-test.org/FileAPI/url/sandboxed-iframe.html). So something else must be going on here. Some potential issues:

- our current implementation of the blob origin registry is thread-local, since our current implementation of origins isn't thread safe, so we have no way of representing the same unique origin on multiple threads.
- the above point also means that only the renderer process can check for the same-originness of unique origins.

I believe dcheng@ or maybe somebody else had some CL at some point that tried to add a UUID to unique origins to support equality checks both cross thread and cross process, but that never seems to have landed.

(also to try to eliminate some possible confusions: a blob itself isn't tied to any particular origin, it is only the blob URL that is tied to a origin).

Oh, and it might be that I accidentally fixed this specific bug already. In the past our BlobURLOriginMap was part of the BlobRegistry code, which only was hit for blob URLs that are actually mapped to blobs. This particular sample I believe doesn't actually use blobs, but instead uses object URLs backed by media sources, and that code did indeed not handle unique origin contexts correctly.

In https://chromium.googlesource.com/chromium/src/+/c1f7232f5d009dfe04f12d99801cf9b007f18131I moved the mapping to PublicURLManager, so now all blob URLs correctly get their origin mapped, and indeed, in M66 this sample does seem to work (or at least goes further, I don't see video but that might be because my chromium build doesn't support the right video codecs? I at least don't get any blob URL related errors).