Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upImplement various checks on the Location setters #26231
Conversation
highfive
commented
Apr 20, 2020
|
Heads up! This PR modifies the following files:
|
|
Great work! Thanks for figuring out all those details. I think there are a few steps missing(although you could open an issue and leave that as a follow-up if there is a reason for that), and I have a small suggestion re the Also, could you please squash into one commit? I think while it's a good idea to separate unrelated work into commits, in this case it is actually related and consolidating the work into a commit would appear clearer. |
| self.check_same_origin_domain()?; | ||
| // Step 3: Let copyURL be a copy of this Location object's url. | ||
| let copy_url = self.get_url(); | ||
| // Step 4: If copyURL's cannot-be-a-base-URL flag is set, terminate these steps. |
This comment has been minimized.
This comment has been minimized.
gterzian
Apr 21, 2020
Member
Are we doing step 5 currently? If not, I think we can do it using as_mut_url().set_path.
This comment has been minimized.
This comment has been minimized.
utsavoza
Apr 21, 2020
•
Author
Contributor
Oh, I assumed we were executing those steps as a part of url::quirks::set_path through UrlHelper::SetPathname, but those steps seem to correspond to dom url spec. I'll add those steps here.
| // Step 3: Let copyURL be a copy of this Location object's url. | ||
| let copy_url = self.get_url(); | ||
| // Step 4: If copyURL cannot have a username/password/port, then return. | ||
| // https://url.spec.whatwg.org/#cannot-have-a-username-password-port |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
utsavoza
Apr 21, 2020
•
Author
Contributor
There's one caveat though when setting port directly via as_mut_url().set_port - we'll have to manually verify and parse the input string to Option<u16>. However, we can use url::quirks::set_port to check and set the port here instead of UrlHelper::SetPort. Please let me know if I'm overlooking any better way to solve this.
This comment has been minimized.
This comment has been minimized.
| // same origin-domain with the entry settings object's origin, then | ||
| // throw a "SecurityError" DOMException. | ||
| self.check_same_origin_domain()?; | ||
| self.set_url_component(value, UrlHelper::SetSearch); |
This comment has been minimized.
This comment has been minimized.
gterzian
Apr 21, 2020
•
Member
I think we're missing step 4 and 5 here? It looks like set_query can be used for step 4, and step 5 would be those additional manipulation of input and copyUrl before calling set_url_component.
This comment has been minimized.
This comment has been minimized.
utsavoza
Apr 21, 2020
•
Author
Contributor
Again, I presumed those steps as a part of UrlHelper::SetSearch. I'll add the required steps here.
| let copy_url = self.get_url(); | ||
| // Step 4: If copyURL's cannot-be-a-base-URL flag is set, terminate these steps. | ||
| if !copy_url.cannot_be_a_base() { | ||
| self.set_url_component(value, UrlHelper::SetHostname); |
This comment has been minimized.
This comment has been minimized.
gterzian
Apr 21, 2020
•
Member
How about we add a copy_url argument to set_url_component to avoid all those double calls to get_url(for algorithms that need the url before calling set_url_component)?
We could also add a documentation to set_url_component to note that it is supposed to match the steps related to https://url.spec.whatwg.org/#concept-basic-url-parser and https://html.spec.whatwg.org/multipage/history.html#location-object-setter-navigate, and then at the call site we could also comment to which local steps in the algorithm the call corresponds.
This comment has been minimized.
This comment has been minimized.
utsavoza
Apr 21, 2020
Author
Contributor
I think we can actually remove the method completely - the only place we might actually need this method after adding checks would be for SetPort method probably (as we might not directly setting port to the url there). For the rest of the setters, we can directly call the navigate method with the appropriate arguments.
Agreed. I'll squash into one commit once the changes are approved. |
d6d739a
to
63d311b
|
Looks like a big improvement in the correctness of the implementation! Just one nit left, and then after you squash I'll approve it(after which we might still have to deal with some surprise failures on the test run). |
| let mut copy_url = self.get_url(); | ||
| // Step 4: Let input be the given value with a single leading "#" removed, if any. | ||
| // Step 5: Set copyURL's fragment to the empty string. | ||
| // Step 6:Basic URL parse input, with copyURL as url and fragment state as |
This comment has been minimized.
This comment has been minimized.
| // Step 3: Let copyURL be a copy of this Location object's url. | ||
| let copy_url = self.get_url(); | ||
| // Step 4: If copyURL cannot have a username/password/port, then return. | ||
| // https://url.spec.whatwg.org/#cannot-have-a-username-password-port |
This comment has been minimized.
This comment has been minimized.
@gterzian Thanks! I have made the suggested change, and squashed all commits into one.
Actually, I ran the wpt tests for the location interface locally. Apart from that how do I verify if we aren't breaking anything else? |
4b8fc42
to
79cffb3
We have to basically run the whole suite and see, there can also be tests that unexpectedly start passing... |
|
Thanks for the awesome work! @bors-servo r+ |
|
|
Implement various checks on the Location setters Since there are no existing open PRs for the issue, I am raising one based on the work done by @UxioAndrade and @braddunbar in previous two PRs for the issue (#25714 and #23670) respectively. - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #23522 - [x] There are tests for these changes
|
|
|
This one seems relevant:
This one does not seem relevant(I'm not sure what intermittent issue it would match by the way):
|
|
Ok the first one might actually be a new intermittent, perhaps you fixed something that makes it show up, and since it seems related to navigation, it's probably best done in a follow up. So please take a look, and if it doesn't appear to point out an issue with this PR, just file an issue for it(if there isn't one already) and add the "intermittent" label to it. |
|
@bors-servo try=wpt |
|
this one seems defenitely relevant:
|
| Err(e) => return Err(Error::Type(format!("Couldn't parse URL: {}", e))), | ||
| }; | ||
| // Step 3: Location-object-setter navigate to the resulting URL record. | ||
| let referrer = Referrer::ReferrerUrl(base_url.clone()); |
This comment has been minimized.
This comment has been minimized.
gterzian
Apr 22, 2020
•
Member
Ok I think this is the problem with /html/browsers/browsing-the-web/navigating-across-documents/source/navigate-child-function.html, the referrer should be not from the entry document but from self.window.Document, at least that is what I make from the test failure(so it's not a new intermittent and not actually related much to navigation).
The test has a page call a method on an iframe, so the page is the "entry document" whose url would be the base url, however the referrer should still be url of the iframe itself.
This comment has been minimized.
This comment has been minimized.
utsavoza
Apr 22, 2020
Author
Contributor
Ahh, right. The referrer url shouldn't be from entry document here - I think let referrer = Referrer::ReferrerUrl(self.get_url()); should fix this.
|
I was able to find six relevant test failures:
and one NOT known-intermittent (as pointed out by @gterzian) from the logs:
I will try to resolve these and post any updates here. |
|
Filed #26269 for the new unrelated intermittent test result. |
|
@utsavoza awesome, sounds like it's worth updating this PR with your work and we'll give the test suite another try... |
Implement various checks on the Location setters Set correct referrer url before for href location setter Update wpt-metadata for failing tests Try updating tests/wpt/metadata/url/failure.html.ini
9c07854
to
b10de77
|
Done! |
|
@utsavoza Thanks for completing this, it was a lot of additional work in the end! @bors-servo r+ |
|
|
Implement various checks on the Location setters Since there are no existing open PRs for the issue, I am raising one based on the work done by @UxioAndrade and @braddunbar in previous two PRs for the issue (#25714 and #23670) respectively. - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #23522 - [x] There are tests for these changes
|
|
Implement various checks on the Location setters Since there are no existing open PRs for the issue, I am raising one based on the work done by @UxioAndrade and @braddunbar in previous two PRs for the issue (#25714 and #23670) respectively. - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #23522 - [x] There are tests for these changes
|
|
|
@bors-servo retry |
|
|
utsavoza commentedApr 20, 2020
Since there are no existing open PRs for the issue, I am raising one based on the work done by @UxioAndrade and @braddunbar in previous two PRs for the issue (#25714 and #23670) respectively.
./mach build -ddoes not report any errors./mach test-tidydoes not report any errors