You are most welcome!

Tested the issue on chrome reported version# 67.0.3396.99 using Mac 10.12.6 with steps mentioned below:
1) Launched chrome reported version and navigated to URL: https://s3.amazonaws.com/hp-life-content/Tech+Class+Academy/Sales+Forecasting/Spanish/ES+(EDCAST)/SF_BC_ES1/story_content/external_files/SFC_Additional%20Excel%20Tips_ES.pdf
2) PDF got loaded successfully

@Reporter: Please find the above mentioned steps and let us know if we missed anything in reproducing the issue, provide your feedback on it which help in further triaging it.

Thanks!

Please find the steps I have followed for testing, 
- Uploaded the file on S3(articulate)
- added link into the edX platform (It has iframe)so that I can view from front end.
- I have tried from front end as shown in the video file attached.
- I can view the same file on Mozilla & IE browser

Do let me know If want more information's or we can go on a call (WebEx, skype).

Thanks!

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

Is this a behaviour that previously worked and was broken in M67 or is it something that has not worked previously?

Are you able to provide a public facing example webpage demonstrating this issue?

yes, It was working previously. We were able to work with these files.

The issue happened from the last release (Unsure about the version).

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

Re#8: I wasn't able to reproduce, is this just a regular hyperlink or is it doing a window.open() ? Can you share more details on how to reproduce?

Also, after opening the PDF, can you check on the Task Manager (shift+esc) if there's a Chrome PDF Plugin shown?

+alexmos, lukasza since this may be related to enabling OOPIFs, it looks like some kind of visibility bug.

Some more questions (I wish there was a public repro page, so I could answer some of these myself):

- If this is a regular hyperlink (rather than |window.open| or something similar), are there any special attributes on it (like <a= rel=noopener ...>)?

- Does the issue go away when ctrl-clicking the link (or right-clicking and choosing "Open link in new tab" from the context menu)?

- Does the issue go away after opting out of field trials of Site Isolation, by visiting chrome://flags#site-isolation-trial-opt-out, choosing "Opt-out (not recommended)," and restarting Chrome?

It would be great If I can Invite anyone to the course and try the steps. Also, It would be great If we can join on a Skype call/WebEx. It would be easy for you to understand.

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

yes, If I try to right click and open in new tab then it works correctly.

I found that the reason for PDF not showing up is that it is probably being opened from a sandboxed frame. If a frame is sandboxed then it cannot load plugins. If we can't load plugins, we cant show PDF in Chrome. So long as 'sandbox' is mentioned for any of the parent frames of the opener of the new tab, PDF won't work.


I assume Firefox does not rely on plugins for showing PDF (I guess they use JS only?); hence the behavior difference.

For the record, this line of code hits in Chrome:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/frame/local_dom_window.cc?rcl=71a945b8cdd7a2780951d3a482f9b58e2bf03e53&l=304

A simple test to show case the difference in behavior is navigating the a tab to this:
data:text/html, <iframe sandbox="allow-script" src="some_pdf"></iframe>

where firefox properly loads the PDF and chrome shows an empty <iframe>.

All in all, I suggest this is a won't fix.

+mkwst@ and alexmos@ for frame sandboxing expertise
+dsinclair@ and tsepez@ for pdf plugin / security expertise
+creis@ for rel=noopener discussion

It is quite unfortunate that implementation details of different browsers (i.e. whether handling of PDFs is implemented via a plugin or not) result in different behavior of sandboxed frame.  Let me add Hotlist-Interop label - I hope that this will attract attention of interop people to this bug.

It is also worth noting that the PDF plugin is fairly restrictive:
- the pdf plugin runs sandboxed in a process separate from web content and the process is bound to a specific site/origin (see issue https://bugs.chromium.org/p/chromium/issues/detail?id=809614)
- it doesn't implement the full breadth of PDF/Javascript bindings) and maybe therefore we could consider relaxing
Because of the restrictiveness, I am not sure if PDF plugin should be subjected to the same sandbox rules as a Flash plugin.

I am also not quite sure if a sandboxed frame can somehow "shed" the sandbox (one one hand this is obviously undesirable from security perspective, but OTOH a ctrl-click would already shed the sandbox [is that a separate security issue?]).  For example - should a frame opened from a sandboxed frame via <a rel=noopener target=_blank> retain or shed sandbox?

Hmm, TIL about "allow-popups-to-escape-sandbox" flag. So perhaps use this on the <iframe> if this is not too much of a security concern for the embedded contents?

FWIW, I'd love to make 'noopener' also escape the sandbox; there are likely security/compatibility implications to making that change, though. As Ehsan says, "allow-popups allow-popups-to-escape-sandbox" will cause any newly opened windows to be sandbox-free, as a workaround.

+foolip for interop.

> It is quite unfortunate that implementation details of different browsers [...] result in different behavior of sandboxed frame.

Indeed. This is an interop issue unlike many others, in that there's no spec that says what the "right" behavior is, indeed whether a browser is able to render PDF itself (as opposed to downloading it) is not consistent.

However, if our PDF implementation executes any kind of code in PDFs, then it would make sense to me to not allow it without "allow-script". This would be similar to an SVG in an <img>, where scripts aren't executed.

Do other browsers support "fancy" PDF features inside of sandboxed iframes? That would seem odd, to me.