resource://foo// resolves to parent directory when the directory pointed at by resource://foo/ doesn't exist

RESOLVED FIXED in Firefox 58

Status

()

defect
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: glandium, Assigned: glandium)

Tracking

unspecified
mozilla58
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox58 fixed)

Details

Attachments

(1 attachment)

This made netwerk/test/unit/test_bug337744.js break after bug 1403366.

STR:
  - Open a scratchpad in a browser context
  - Enter the following script:

Cu.import("resource://gre/modules/NetUtil.jsm");
Cu.import("resource://gre/modules/Services.jsm");

var uri = NetUtil.newURI("http://www.example.com");
var principal = Services.scriptSecurityManager.createCodebasePrincipal(uri, {});

var resProto = Cc['@mozilla.org/network/protocol;1?name=resource'].getService(Ci.nsIResProtocolHandler);
var file = Cc["@mozilla.org/file/local;1"].createInstance(Ci.nsIFile);
file.initWithPath("/this/directory/does/not/exist");
var rootURI = Services.io.newFileURI(file);

resProto.setSubstitution("res-test", rootURI);

var channel = NetUtil.newChannel({
  uri: NetUtil.newURI("resource://res-test//"),
  loadingPrincipal: principal,
  securityFlags: Ci.nsILoadInfo.SEC_ALLOW_CROSS_ORIGIN_DATA_IS_NULL,
  contentPolicyType: Ci.nsIContentPolicy.TYPE_OTHER
});

channel.name

- Click "Display"

Expected result:
  /this/directory/does/not/exist//

Actual result:
  /this/directory/does/not//
So the problem is that when creating the URI from the file, when the directory exists, Services.io.newFileURI returns a URI that ends with a /, but not when the file doesn't exist, which makes sense.

Then, when the substituting protocol handler creates the resolved uri, it adds resolves './path' from that uri that doesn't end with a /, which makes it relative to the parent directory.
Assignee: nobody → mh+mozilla
Blocks: 1403366
Comment on attachment 8914630 [details]
Bug 1405174 - Fix resolution of resource: URLs when the target of the substitution doesn't end with a /.

This adds multiple slashes to the resulting path, and jar: urls don't like that, so that breaks omni.ja urls :(
Attachment #8914630 - Flags: review?(valentin.gosu)
Comment on attachment 8914630 [details]
Bug 1405174 - Fix resolution of resource: URLs when the target of the substitution doesn't end with a /.

https://reviewboard.mozilla.org/r/185952/#review191010

Thanks for adding a test for this!
Attachment #8914630 - Flags: review?(valentin.gosu) → review+
Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/autoland/rev/9c05226e2248
Fix resolution of resource: URLs when the target of the substitution doesn't end with a /. r=valentin
Backed out

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=9c05226e2248004f91a7487016612d32b39184d7&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=usercancel&filter-resultStatus=runnable

Failure log https://treeherder.mozilla.org/logviewer.html#?job_id=134783673&repo=autoland
> TEST-UNEXPECTED-FAIL | netwerk/test/browser/browser_child_resource.js | Should resolve in main process - Got chrome://global/content/global.xul/test.js, expected chrome://global/content/test.js

Failure log https://treeherder.mozilla.org/logviewer.html#?job_id=134777743&repo=autoland
TEST-UNEXPECTED-FAIL | toolkit/components/addoncompat/tests/browser/browser_addonShims.js | Test timed out -
TEST-UNEXPECTED-FAIL | toolkit/components/addoncompat/tests/browser/browser_addonShims.js | test left unexpected property on window: runAddonShimTests -
TEST-UNEXPECTED-FAIL | toolkit/components/addoncompat/tests/browser/browser_addonShims.js | Found a tab after previous test timed out: resource://addonshim1/page.html -
Flags: needinfo?(mh+mozilla)
Backed out for failing browser-chrome's toolkit/components/addoncompat/tests/browser/browser_addonShims.js and netwerk/test/browser/browser_child_resource.js:

https://hg.mozilla.org/integration/autoland/rev/c7de45b3805a1a2b567509d65d2b8c9e3c21d750
The problem with netwerk/test/browser/browser_child_resource.js is that it's setting resource urls to "root" chrome urls, and root chrome urls autoexpand to contain a file name.

That is, Services.io.newURI("chrome://global/content").spec is "chrome://global/content/global.xul", and Services.io.newURI("chrome://global/skin").spec is "chrome://global/skin/global.css".

per https://dxr.mozilla.org/mozilla-central/rev/11fe0a2895aab26c57bcfe61b3041d7837e954cd/chrome/nsChromeProtocolHandler.cpp#87

So, when doing e.g. resProtocol.setSubstitution("testing", Services.io.newURI("chrome://global/content"));, what really happens is resProtocol.setSubstitution("testing", Services.io.newURI("chrome://global/content/global.xul")); and the changes in this bug are breaking the assumptions that follow in the test.

There is absolutely no way to get a pure "chrome://global/content/" url, so something using such chrome urls as resource targets *are* relying on the current behavior of file-relative resolution stripping off the file name...

A way out of this is to only apply the changes in this bug to nsIFileURL (opt-in), or to exclude based on mozilla::dom::IsChromeURI() (opt-out).

Another would be for chrome urls to stop being magic, but I bet this would break a lot of stuff.

As for toolkit/components/addoncompat/tests/browser/browser_addonShims.js, it's kind of the same problem. It uses Services.io.newURI("chrome://addonshim1/content/"), which transforms that to chrome://addonshim1/content/addonshim1.xul, and asks the chrome registry to expand that, so it gets back a jar: uri that points to the xul file in a xpi.

Going through all the things that use setSubstitution, apart from those two tests that failed, only toolkit/components/search/tests/xpcshell/test_require_engines_in_cache.js does something fishy that the changes in this bug could break: resProt.setSubstitution("search-plugins", Services.io.newURI("about:blank")); but it's only trying to read the url as a directory.

Anyways, I think the reasonable way forward here is to only do the changes for nsIFileURL.
Flags: needinfo?(mh+mozilla)
Attachment #8914630 - Flags: review+ → review?(valentin.gosu)
Attachment #8914630 - Flags: review?(valentin.gosu)
Comment on attachment 8914630 [details]
Bug 1405174 - Fix resolution of resource: URLs when the target of the substitution doesn't end with a /.

https://reviewboard.mozilla.org/r/185952/#review191626

This looks good, but I'd love to see even more tests for it. There seem to be loads of corner cases here.
Attachment #8914630 - Flags: review?(valentin.gosu) → review+
(In reply to Valentin Gosu [:valentin] from comment #12)
> Comment on attachment 8914630 [details]
> Bug 1405174 - Fix resolution of resource: URLs when the target of the
> substitution doesn't end with a /.
> 
> https://reviewboard.mozilla.org/r/185952/#review191626
> 
> This looks good, but I'd love to see even more tests for it. There seem to
> be loads of corner cases here.

I don't think there's any corner case left that is not tested, considering the patch only affects nsIFileURLs now.
Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/autoland/rev/8aeb6541520a
Fix resolution of resource: URLs when the target of the substitution doesn't end with a /. r=valentin
Flags: needinfo?(mh+mozilla)
Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/autoland/rev/32c618d07fe1
Fix resolution of resource: URLs when the target of the substitution doesn't end with a /. r=valentin
https://hg.mozilla.org/mozilla-central/rev/32c618d07fe1
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
You need to log in before you can comment on or make changes to this bug.