Blob URL should not ignore query or fragment
Categories
(Core :: DOM: File, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox75 | --- | fixed |
People
(Reporter: evilpie, Assigned: evilpie)
References
Details
Attachments
(1 file)
There are a bunch of test failures at https://jgraham.github.io/wptdash/?bugComponent=core%3A%3Adom%3A+file, which are caused by us ignoring fragments and query parameters on blob: URLs. I think this could be fixed by modifying this code. The question is if that is going to cause other failures.
Comment 1•5 years ago
|
||
Do you have a try-push result to see what breaks? Maybe it breaks invalid tests.
Comment 2•5 years ago
|
||
Presumably removing the fragment is still correct; the only question is what should happen for the query part, right?
Assignee | ||
Comment 3•5 years ago
|
||
It seems like #fragment is supposed to be ignored when fetching, but not for URL.revokeObjectURL. So just changing that one place doesn't work.
Assignee | ||
Comment 4•5 years ago
|
||
I submitted the incorrect patch to try anyway: https://treeherder.mozilla.org/#/jobs?repo=try&revision=83c029e9b82996e27e4a9ee4933318d09c98e886
Comment 5•5 years ago
•
|
||
One plausible thing we could do:
- Only strip fragment here, not query.
- Have an explicit check for fragment at the entrypoint of URL.revokeObjectURL and no-op if it's present (like we would for any non-matching URL).
I think that will generally give the right behavior, right?
Comment 6•5 years ago
|
||
Plus we'd want to make sure the specs make all this clear...
Comment 7•5 years ago
|
||
What part of the spec is unclear?
https://w3c.github.io/FileAPI/#blob-url-resolve
https://w3c.github.io/FileAPI/#dfn-revokeObjectURL
Comment 8•5 years ago
|
||
Just to be clear, I have not had a close look at the spec. Those two links are quite clear, yes, and not what we do.
Internally we have a bunch of other callsites into this code and it's not obvious to me whether they correspond to spec operations or not.
Comment 9•5 years ago
|
||
Tom, are you able to continue to work on this or should I triage to the team? Thanks
Assignee | ||
Comment 10•5 years ago
|
||
I can try implementing comment 5, but I can't promise that I will be able to dig into hundreds of failures when that doesn't work.
Assignee | ||
Comment 11•5 years ago
|
||
Comment 12•5 years ago
|
||
Comment 13•5 years ago
|
||
bugherder |
Description
•