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 upFix revoke blob url #24685
Fix revoke blob url #24685
Conversation
highfive
commented
Nov 7, 2019
|
Thanks for the pull request, and welcome! The Servo team is excited to review your changes, and you should hear from @nox (or someone else) soon. |
highfive
commented
Nov 7, 2019
|
Heads up! This PR modifies the following files:
|
highfive
commented
Nov 7, 2019
|
@bors-servo try=wpt |
Fix revoke blob url <!-- Please describe your changes on the following line: --> fix #24290 --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: --> - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #24290 (GitHub issue number if applicable) <!-- Either: --> - [ ] There are tests for these changes OR - [ ] These changes do not require tests because ___ <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
|
|
|
Hmm, the goal of #24290 was to get tests/wpt/web-platform-tests/FileAPI/url/url-with-xhr.any.js and tests/wpt/web-platform-tests/FileAPI/url/url-with-fetch.any.js passing, so it's curious that there is no change in test results. |
| FileManagerThreadMsg::RevokeBlobURL(id, origin, sender) => { | ||
| let _ = sender.send(self.store.set_blob_url_validity(false, &id, &origin)); | ||
| FileManagerThreadMsg::RevokeBlobURL(url, sender) => { | ||
| if let Ok((id, origin)) = parse_blob_url(&url) { |
This comment has been minimized.
This comment has been minimized.
jdm
Nov 7, 2019
Member
Oh - we still are throwing away the fragment and query string from the URL, which is why the tests continue to fail. We need to explicitly deal with those.
This comment has been minimized.
This comment has been minimized.
|
I have two quesrtions. 1. About parse_blob_urlparse_blob_url gets uuid and origin from url. ex.
And, CreateObjectURL seems to store uuid as key.(because it call set_blob_url_validity.) servo/components/net/filemanager_thread.rs Line 679 in e5689df So I think that it is correct that RevokeObjectURL uses uuid as key and uses parse_blob_url. 2. About failed tests.I ran the test in my local(macOS Mojave 10.14.6).
Is this the error you said? And, I tried adding the following to url-with-fetch.any.js. ...
const result = fetch_should_succeed(t, url).then(text => {
assert_equals(text, blob_contents);
});
// added code
for (i = 0; i < 1000; i ++) {
console.log("aaaa");
}
// Revoke the object URL. fetch should have already resolved the blob URL.
URL.revokeObjectURL(url);
return result;
}, 'Revoke blob URL after calling fetch, fetch should succeed');And, I got the following result.
So, I think that the cause of the error is the fetch timing. Is this correct? |
|
r? @jdm |
|
@shnmorimoto With respect to the test output, when a test says:
That means that the test results matched the expected results. For that test, they are present in this file, which shows that various subtests are currently expected to fail. By making the changes I recommend, our goal is to make the subtests pass and remove these expected failures. As for the question about parse_blob_url, rather than my original suggestion (make the RevokeBlobURL message accept a URL argument), I think we should modify parse_blob_url to return an Err if the parsed URL contains a fragment or query string. This should achieve the same goal - revoking a blob URL that has a fragment ( |
|
@jdm I misunderstood the test output. Thank you for the detailed explanation.
I understand. I will fix it that way. |
999818e
to
bc9de39
|
@jdm I've fixed it. For fragment, there are following test. promise_test(t => {
const url = URL.createObjectURL(blob);
return fetch_should_succeed(t, url + '#fragment').then(text => {
assert_equals(text, blob_contents);
});
}, fetch_method + ' with a fragment should succeed');So, It is only checked in RevokeObjectURL. What do you think? |
|
Good find. I agree! |
|
Thanks! I fixed it as follows and already pushed. if let Ok(url) = ServoUrl::parse(&url) {
if url.fragment().is_none() && origin == get_blob_origin(&url) {I ran the test locally and confirmed that the results changed.
|
|
Please include the updated test results in this PR, in that case :) |
|
You can use |
bc9de39
to
570adf2
|
Oh, Sorry. I updated test results. I still get unexpected results locally.
But, I get same results with master branch too. |
|
|
570adf2
to
be3cc5c
be3cc5c
to
2d995ba
|
I did rebase and resolved merge conflicts. |
|
@bors-servo r+ |
|
|
Fix revoke blob url <!-- Please describe your changes on the following line: --> fix #24290 --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: --> - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #24290 (GitHub issue number if applicable) <!-- Either: --> - [ ] There are tests for these changes OR - [ ] These changes do not require tests because ___ <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
|
|
|
@bors-servo retry |
|
|
Fix revoke blob url <!-- Please describe your changes on the following line: --> fix #24290 --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: --> - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #24290 (GitHub issue number if applicable) <!-- Either: --> - [ ] There are tests for these changes OR - [ ] These changes do not require tests because ___ <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
|
|
shnmorimoto commentedNov 7, 2019
fix #24290
./mach build -ddoes not report any errors./mach test-tidydoes not report any errors