-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add preload tests from Blink. #4316
Add preload tests from Blink. #4316
Conversation
<script> | ||
var t = async_test('Makes sure link preload preloaded resources are not delaying onload'); | ||
</script> | ||
<link rel=preload href="resources/dummy.js?pipe=trickle(d1)" as=script> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a possible source of unstable results. Maybe something like 5 seconds? @jgraham
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think the time it'd take the browser to run the test and get to window.load() would exceed 1 second? I'd hate to make this test slower if it's not a must
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jgraham can comment on this more but AIUI the experience when testing (on devices in particular) is that there can be slowness in the network stack for various reasons, and assuming that network will have responded in less than 2 seconds has resulted in unstable test results. (This applies to all trickle()
/timeouts in this PR, not just this line.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, bumped up the trickle values
<link rel=preload href="resources/square.png" as=image> | ||
<script> | ||
window.addEventListener("load", t.step_func(function() { | ||
setTimeout(t.step_func(function() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use t.step_timeout
and a longer timeout (2000ms I think)
t.done(); | ||
})); | ||
document.write('<sc' + 'ript src="resources/dummy.js?pipe=trickle(d1)"></sc' + 'ript>'); | ||
document.write("<!--"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the point/purpose of the unclosed comment? Would it be simpler and cleaner to simply build and append a script element?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, it would be. I'll switch to that.
link.href = ""; | ||
window.addEventListener("load", t.step_func(function() { | ||
assert_equals(performance.getEntriesByType("resource").length, 3); | ||
t.done(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I follow this test. How does this verify that the preload response is aborted? Meta: does abort even make sense? The browser should start a new download if href is mutated, but it's not clear that the old one can/should be stopped.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It verifies that by seeing 3 resources in RT rather than 4. I could make it explicit looking at a particular URL.
I was following the spec's processing model: "The user agent should abort the current request if the href attribute of the link element of a preload link is changed, removed, or its value is set to an empty string." (which IMO makes sense)
t.done(); | ||
})); | ||
</script> | ||
<script src="resources/dummy.js?pipe=trickle(d0.2)"></script> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto to above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, unlike the above, that behavior is actually not defined. There's no mutation when link is removed from the document. Should we define it as such? (I'd argue that it should be similar to href being removed or set to an empty string)
rel removal is also not defined as a mutation or something the UA should abort on, and probably should be.
<link rel=preload href="non-existent/test.mp4" as=video onerror="videoFailed = true;"> | ||
<link rel=preload href="non-existent/test.oga" as=audio onerror="audioFailed = true;"> | ||
<link rel=preload href="non-existent/security/captions.vtt" as=media onerror="trackFailed = true;"> | ||
<link rel=preload href="non-existent/dummy.xml" as=foobarxmlthing onerror="gibrishFailed = true;"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gibberish? :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
didn't bother to typo check that word, apparently :D
t.done(); | ||
})); | ||
</script> | ||
<span>PASS - this text is here just so that the browser will download the font.</span |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing >
!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! :)
#4316 (comment) is still outstanding comment. (Making tests take longer to run is bad, but having people spend time analyzing unstable results is worse...) |
Changed the trickle values to higher ones. I'll try to see in follow up PRs if I can somehow collapse the tests, so that we'd wait on these long timeouts once, rather than multiple times... |
Thanks! Checking test results in https://travis-ci.org/w3c/web-platform-tests/builds/184496213 ... /preload/preload_with_type.html fails in Chrome. Is that expected? /preload/dynamic_adding_preload.html times out in Firefox. Could it be made to fail reliably (maybe fail early with a feature-check?)? |
The failure in Chrome is expected (Noticed it while writing the tests). I can fix it first before landing the tests, if that helps. I'll look into the Firefox timeouts |
It's perfectly fine to land tests that fail, just wanted to check that it was expected. |
@@ -7,13 +7,17 @@ | |||
<body> | |||
<script> | |||
var link = document.createElement("link"); | |||
if(!link.rellist || !link.rellist.supports("preload")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be relList
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup
link.as = "script"; | ||
link.rel = "preload"; | ||
link.href = "resources/dummy.js"; | ||
link.onload = t.step_func(function() { | ||
link.onload = t.step_timeout(function() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no spec guaranty that the PerformanceEntry is added to the timeline before the resource's onload handler runs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
on second thought, you're right. I'll rewrite
@@ -7,13 +7,17 @@ | |||
<body> | |||
<script> | |||
var link = document.createElement("link"); | |||
if(!link.rellist || !link.rellist.supports("preload")) { | |||
assert_unreached("rellist is not defined or browser doesn't support preload."); | |||
t.done(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need for this line, the line above throws an exception.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
@zcorpan: addressed your comments |
w3c-test:mirror |
</script> | ||
<body> | ||
<script> | ||
var link = document.createElement("link"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrap everything in t.step(function() { ... })
(or use async_test(function(t) { ... })
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
Thanks @igrigorik and @zcorpan for reviewing! (and @sideshowbarker for merging :D) |
This PR adds tests for preload from Blink's layout tests.
These tests are not necessarily a complete test suite as they were built during the feature's implementation, and complemented in Blink by various tests that require internal APIs as well as unit tests. I plan to iterate over these tests and make sure they provide adequate coverage.
/cc @zcorpan @igrigorik