-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Add nested-context resource-timing tests #13823
Conversation
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"); |
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 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...
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.
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.
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. 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?
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.
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.
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.
Are there follow-up issues for this?
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.
w3c/resource-timing#39 is the umbrella issue for that. w3c/resource-timing#12 was the more specific one that covered failed fetches
@bzbarsky - PTAL? |
@bzbarsky - friendly ping :) |
@bzbarsky - post holidays ping :) |
5bf797d
to
dbdc1c2
Compare
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 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. |
4bbc152
to
06075fb
Compare
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.
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.
Firefox appears to pass all these tests, FWIW. |
I didn't have them initially, but will add just to be on the safe side.
We need the full URL for the |
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.
@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) { |
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 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; |
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.
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.
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.
But this test is already cross-origin between localhost and some other host, or am I missing something?
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.
IIRC, @bzbarsky was asking for cross-origin and cross-site tests (so using hosts that have different domains)
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.
Right but this test is both cross-origin and cross-site if runs from localhost. Maybe what's missing is same-site cross-origin?
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 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.
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.
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.
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.
Gotcha. I wasn't aware of these details. Thanks!
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}
No description provided.