Skip to content
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

Merged
merged 16 commits into from
Dec 19, 2016

Conversation

yoavweiss
Copy link
Contributor

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

@yoavweiss yoavweiss mentioned this pull request Dec 12, 2016
7 tasks
<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>
Copy link
Member

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

Copy link
Contributor Author

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

Copy link
Member

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.)

Copy link
Contributor Author

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() {
Copy link
Member

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("<!--");
Copy link
Member

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?

Copy link
Contributor Author

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();
Copy link
Member

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.

Copy link
Contributor Author

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>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto to above.

Copy link
Contributor Author

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;">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gibberish? :P

Copy link
Contributor Author

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing >!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! :)

@zcorpan
Copy link
Member

zcorpan commented Dec 16, 2016

#4316 (comment) is still outstanding comment. (Making tests take longer to run is bad, but having people spend time analyzing unstable results is worse...)

@yoavweiss
Copy link
Contributor Author

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...

@zcorpan
Copy link
Member

zcorpan commented Dec 16, 2016

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?)?

@yoavweiss
Copy link
Contributor Author

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

@zcorpan
Copy link
Member

zcorpan commented Dec 16, 2016

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")) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be relList

Copy link
Contributor Author

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() {
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Contributor Author

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();
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

@yoavweiss
Copy link
Contributor Author

@zcorpan: addressed your comments

@zcorpan
Copy link
Member

zcorpan commented Dec 16, 2016

w3c-test:mirror

</script>
<body>
<script>
var link = document.createElement("link");
Copy link
Member

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) { ... }))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@sideshowbarker sideshowbarker merged commit e8172dd into web-platform-tests:master Dec 19, 2016
@yoavweiss
Copy link
Contributor Author

Thanks @igrigorik and @zcorpan for reviewing! (and @sideshowbarker for merging :D)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants