问题似乎是由带有
sandbox属性的iframe引起的（例如JSFiddle），因为在这样的iframe之外的链接中不会发生此问题。可以使用以下HTML文件在JSFiddle之外重现此问题。
frame.html:
<iframe sandbox="allow-same-origin allow-forms allow-popups allow-scripts" src="content.html"></iframe>
content.html:
<a href="https://www.adobe.com/enterprise/accessibility/pdfs/acro6_cg_ue.pdf">default</a>
<a href="https://www.adobe.com/enterprise/accessibility/pdfs/acro6_cg_ue.pdf" target="_blank">_blank</a>
<a href="https://www.adobe.com/enterprise/accessibility/pdfs/acro6_cg_ue.pdf" target="_top">_top</a>
使用这些沙盒值， 默认目标
_blank和
_top都无法呈现PDF， 默认在iframe中呈现失败，
_blank和
_top打开新选项卡也失败（由于沙盒化，
_top打开新选项卡）。
如果我们添加 allow-top-navigation 沙盒值，我们就可以使_top按预期工作。
<iframe sandbox="allow-same-origin allow-top-navigation allow-forms allow-popups allow-scripts" src="content.html"></iframe>
然而，由
_blank打开的新标签仍无法呈现PDF。即使我在MDN上添加了所有放宽沙盒限制的属性，问题仍然存在（并不是我期望添加
allow-pointer-lock会有任何作用）。
<iframe sandbox="allow-same-origin allow-top-navigation allow-forms allow-popups allow-scripts allow-pointer-lock" src="content.html"></iframe>
在Chrome 43中，我唯一能让_blank在iframe内工作的方法是完全删除sandbox属性。
<iframe src="content.html"></iframe>
现在默认目标_blank和_top按预期工作。
不幸的是，删除sandbox属性并不是一个很好的解决方法。如果您一开始就使用它，那么您可能有需要它的地方。我不能确定在沙盒iframe中阻止PDF文件是否存在安全原因，但是从用户体验来看，我认为这更可能是一个错误。
我已经为这个问题打开了一个bug报告，并链接回了这个问题：
https://code.google.com/p/chromium/issues/detail?id=505860
更新： 原来这是一项设计安全功能，因此它可能不会返回到Chrome 42的行为，但将来可能会添加新的沙箱选项以放宽此安全功能。
更新-2： 允许此功能的沙箱属性是'allow-popups-to-escape-sandbox'。更多信息在这里。
allow-popups-to-escape-sandbox标志或完全从CSP头部中删除sandbox。太棒了。 - noor