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 nested-context resource-timing tests #13823

Merged
merged 13 commits into from
Mar 13, 2019

Conversation

yoavweiss
Copy link
Contributor

No description provided.

resource-timing/embed-refresh.sub.html Outdated Show resolved Hide resolved
resource-timing/embed-reload-back.html Outdated Show resolved Hide resolved
resource-timing/embed-refresh.sub.html Outdated Show resolved Hide resolved
resource-timing/embed-reload.sub.html Outdated Show resolved Hide resolved
resource-timing/embed-reload.sub.html Outdated Show resolved Hide resolved
if (entry.name == "{{location[scheme]}}://{{host]}}:{{ports[http][0]}}/resource-timing/resources/iframe-that-reloads.html") {
found_first_iframe = true;
}
assert_not_equals(entry.name, "{{location[scheme]}}://{{host]}}:{{ports[http][0]}}/resource-timing/resources/reloaded_iframe.html", "Reloaded iframe should not be observable");
Copy link
Contributor

Choose a reason for hiding this comment

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

This will always pass, because there is no "reloaded_iframe.html" anywhere in these tests. Similar things with "refreshed_iframe.html" in some of the other tests. So this is not testing what it thinks it's testing.

I wonder whether it's feasible to have a complete whitelist of resource timing names that should be present, and fail the test if they're not all present or if something else is present. That would avoid issues like this...

I'm going to hold off on the rest of this review until the above issues are addressed, because they will significantly affect the readability of the tests, and possibly the logic flow...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed! Good catch

I wonder whether it's feasible to have a complete whitelist of resource timing names that should be present, and fail the test if they're not all present or if something else is present. That would avoid issues like this...

There seem to be differences between browsers on that front (which is not great...), so better not go the whitelist route.

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm. What are the differences? Could we have a list of must-haves and a list of may-haves, maybe? And file bugs on specs and/or browsers as needed to eliminate the may-haves?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

One difference ATM is failed fetches (See them in Firefox, but not Chrome), which is currently a MAY in the spec.
Once we'll define a stricter processing model, I think we can also align the implementations on a stricter behavior, where the entries are predictable in all engines.

Copy link
Member

Choose a reason for hiding this comment

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

Are there follow-up issues for this?

Copy link
Contributor Author

@yoavweiss yoavweiss Mar 12, 2019

Choose a reason for hiding this comment

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

w3c/resource-timing#39 is the umbrella issue for that. w3c/resource-timing#12 was the more specific one that covered failed fetches

@yoavweiss
Copy link
Contributor Author

@bzbarsky - PTAL?

@yoavweiss
Copy link
Contributor Author

@bzbarsky - friendly ping :)

@yoavweiss
Copy link
Contributor Author

@bzbarsky - post holidays ping :)

Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

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

It also seems like a lot of the JavaScript could be abstracted somehow as the files look very similar. That would also help in reviewing them (and presumably when adding more tests at some point).

I hope this high-level review is useful.

I haven't run these yet, but if there's browser failures, are there bugs filed on those?

resource-timing/embed-navigate-back.html Outdated Show resolved Hide resolved
lint.whitelist Outdated Show resolved Hide resolved
resource-timing/embed-navigate-back.html Outdated Show resolved Hide resolved
@yoavweiss
Copy link
Contributor Author

It also seems like a lot of the JavaScript could be abstracted somehow as the files look very similar. That would also help in reviewing them (and presumably when adding more tests at some point).

I hope this high-level review is useful.

I haven't run these yet, but if there's browser failures, are there bugs filed on those?

Thanks for reviewing! :)

I tidied up and coalesced the JS.

Haven't filed bugs yet, but I will.

@yoavweiss yoavweiss force-pushed the resource-timing-nested branch from 4bbc152 to 06075fb Compare March 12, 2019 19:19
Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

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

A thing I noticed is that there's no cross-origin tests anymore. Is that intentional? /common/get-host-info.sub.js should make those relatively easy to add to add.

Without cross-origin it's not really clear to me why you'd even need the URL object here.

resource-timing/embed-navigate-back.html Outdated Show resolved Hide resolved
resource-timing/embed-navigate.html Outdated Show resolved Hide resolved
resource-timing/embed-refresh.html Outdated Show resolved Hide resolved
@annevk
Copy link
Member

annevk commented Mar 13, 2019

Firefox appears to pass all these tests, FWIW.

@yoavweiss
Copy link
Contributor Author

A thing I noticed is that there's no cross-origin tests anymore. Is that intentional? /common/get-host-info.sub.js should make those relatively easy to add to add.

I didn't have them initially, but will add just to be on the safe side.

Without cross-origin it's not really clear to me why you'd even need the URL object here.

We need the full URL for the PerformanceEntry.name comparison.

@annevk annevk merged commit 75913b3 into web-platform-tests:master Mar 13, 2019
@yoavweiss yoavweiss deleted the resource-timing-nested branch March 13, 2019 15:28
Copy link
Contributor

@bzbarsky bzbarsky left a comment

Choose a reason for hiding this comment

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

@yoavweiss @annevk Thank you! This is very readable now and quite clear in terms of what it's doing. My sincere apologies for being so slow on reviewing this... :(

@yoavweiss I really appreciate the work you put into this and you pushing this over the finish line in spite of me timing out on you. Thank you, again.

}
window.addEventListener("message", e=>{
if (e.data == "navigated") {
if (sessionStorage.navigated) {
Copy link
Contributor

Choose a reason for hiding this comment

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

It might have been good to document somewhere the tight coupling between this and the exact test-serialization behavior we get from using promise_test for everything, thus ensuring that we never touch sessionStorage from two different tests in a racy way.

let destination = location;
if (location.search == "?crossorigin") {
const host_info = get_host_info()
destination = location.protocol + "//" + host_info["REMOTE_HOST"] + ":" + location.port;
Copy link
Contributor

Choose a reason for hiding this comment

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

As a followup, it might be good to have not-samesite tests here too, just to test the cross-process case. hostinfo does not expose NOTSAMESITE_HOST at the moment, so that would need to get fixed too... I filed #15819 on that.

Copy link
Contributor

Choose a reason for hiding this comment

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

But this test is already cross-origin between localhost and some other host, or am I missing something?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

IIRC, @bzbarsky was asking for cross-origin and cross-site tests (so using hosts that have different domains)

Copy link
Contributor

Choose a reason for hiding this comment

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

Right but this test is both cross-origin and cross-site if runs from localhost. Maybe what's missing is same-site cross-origin?

Copy link
Contributor

@bzbarsky bzbarsky Feb 8, 2022

Choose a reason for hiding this comment

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

This test does not normally run "from localhost". It runs from one of the defined test hosts in the test configuration. Specifically, from whatever {{host}} expands to. Depends on the harness what that is, but it's generally not localhost, but something more like web-platform.test or wpt.live or whatnot, depending on the test runner configuration.

Copy link
Contributor

@bzbarsky bzbarsky Feb 8, 2022

Choose a reason for hiding this comment

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

And for details, see the get_host_info function's implementation and ORIGINAL_HOST and REMOTE_HOST and NOTSAMESITE_HOST in there. It has provisions for what to do if running from localhost, but also provisions for what to do in other cases. So yes, when running from localhost the test is testing the cross-site case and can't test the same-site cross-origin case at all.... which is why you should not be running these tests from localhost: a bunch of them will fail due to the lack of an available same-site cross-origin host in that setup.

Copy link
Contributor

Choose a reason for hiding this comment

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

Gotcha. I wasn't aware of these details. Thanks!

aarongable pushed a commit to chromium/chromium that referenced this pull request Mar 13, 2019
web-platform-tests/wpt#13823 introduces a
test which is flaky in Chromium, due to a Chromium issue.
This CL will enable that test to be imported without flaking the bots.

Bug: 941482
Change-Id: I7568bd00d55743ab140f428b807cf2ffc92a9fda
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1520601
Commit-Queue: Robert Ma <[email protected]>
Reviewed-by: Robert Ma <[email protected]>
Cr-Commit-Position: refs/heads/master@{#640459}
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.

5 participants