Presence of Content-Security-Policy in meta messes performance API
Reported by
shek...@gmail.com,
Dec 2 2016
|
|||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.10 Safari/537.36
Steps to reproduce the problem:
Given a web page:
```
<!doctype html>
<head>
<meta http-equiv="Content-Security-Policy">
<link rel="preload" href="not-ran.js" as="script">
</head>
<script>
window.addEventListener("load", function() {
var entries = performance.getEntriesByType("resource");
console.dir(entries);
});
</script>
<script crossorigin src="ran.js"></script>
```
and two dummy resources, ran.js and not-ran.js served from the network.
What is the expected behavior?
Expect performance resource type contain two entries.
What went wrong?
Initial load contains two entries, while subsequent (not hard) reload produces only one entry, skipping preloaded resource.
Removing meta element makes entries reliably contain two elements.
Did this work before? N/A
Chrome version: 56.0.2924.10 Channel: dev
OS Version: OS X 10.12.1
Flash Version:
Probably unrelated to security, but definitely related to Content Security Policy implementation.
Discovered while investigating Issue 664816 .
,
Dec 3 2016
,
Dec 5 2016
Tested in chrome # 56.0.2924.14 on Mac 10.11.6 and not able to reproduce the issue with above html code.Please find the screen shots for your reference. @shekyan: Could you please let me know if i have missed anything and if possible, provide us with a valid html / extension URL of the issue which would help us to triage the issue further. Thanks in advance!
,
Dec 5 2016
,
Dec 5 2016
@shekyan: Tested on chrome ## 56.0.2924.14 on Mac 10.11.6 with provided comment#4 files and not able to reproduce the issue.Please find the screen shot for your reference.Could you please let me know if i have missed anything and if possible, provide us with sample test cases of the issue which would help us to triage the issue further. Thanks in advance!
,
Dec 5 2016
YOu keep loading it from local file rather than HTTP.
,
Dec 6 2016
This looks like out of scope for TE, hence adding the respective label for it to triage further.
,
Dec 6 2016
It's not clear to me that this has anything to do with the HTTPEquiv. In each variant of the test page: https://whytls.com/test/csp/noequiv.html - No HTTPEquiv https://whytls.com/test/csp/malformed.html - Malformed CSP with no value https://whytls.com/test/csp/wellformed.html - Wellformed CSP ... refreshing shows that the array length fluctuates between 1 and 2. As I see this behavior even with no HTTPEquiv at all, I think you're actually hitting a corner case with the behavior of the preload.
,
Dec 6 2016
Yep, I should've mentioned that preload has to be there to trigger the fluctuation. Your test results are a little off with what I see. Although I see fluctuation when I load https://whytls.com/test/csp/noequiv.html, I don't see any problems when load the same file from my local web server, which doesn't set `keep-alive`.
,
Feb 14 2017
Something something performance and preload => Hi, Yoav!
,
Feb 14 2017
Thanks Mike! Highly appreciated :D shekyan - I don't see any fluctuation in current Canary with the link you sent. Can you try it and let me know if you still see the issue? Also - how are you reloading the page? (enter on url bar? reload button? cmd+r?)
,
Feb 14 2017
Yoav, still can reproduce on Eric's test-cases (https://bugs.chromium.org/p/chromium/issues/detail?id=670588#c8) on 56.0.2924.87 on MacOS. Refreshing with Cmd+R. Except now subsequent loads do not create any entries in the performance results.
,
Feb 15 2017
I was able to recreate locally, but it happens very rarely... :/ I saw the requests going out. Not sure if both responses made it back safely (which is not, can explain why the preloaded one is not in ResourceTiming). Could also be a ResourceTiming issue. If you happen to find a more consistent case where the preloaded resource is not in ResourceTiming, it'd be highly appreciated...
,
Jul 31 2017
There is no valid updates happened in the last few months, closing the issue. Feel free to reopen if needed. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by elawrence@chromium.org
, Dec 2 2016