Add a getFile method to SpecialPowers

NEW
Unassigned

Status

defect
8 years ago
3 years ago

People

(Reporter: khuey, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Posted patch PatchSplinter Review
This is limited to files in the cwd, but that's good enough for me ATM.  We can always change it later if needed.
Attachment #552702 - Flags: review?(ted.mielczarek)
What is it needed for?
No profile access can occur in specialpowers.js since we don't have a profile in the content process.
(In reply to Josh Matthews [:jdm] from comment #3)
> No profile access can occur in specialpowers.js since we don't have a
> profile in the content process.

I don't understand how that's relevant.
Maybe we should name this getDOMFile? :) (khuey is implementing a way to create DOM File objects.)
(In reply to Ted Mielczarek [:ted, :luser] from comment #5)
> Maybe we should name this getDOMFile? :) (khuey is implementing a way to
> create DOM File objects.)

Sure, I don't care.  We'll never be able to return an nsIFile here though, so I just figured it was unnecessary.
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #4)
> (In reply to Josh Matthews [:jdm] from comment #3)
> > No profile access can occur in specialpowers.js since we don't have a
> > profile in the content process.
> 
> I don't understand how that's relevant.

Whoops, I saw a directory service get and just assumed it was ProfD.
Blocks: 673742
Comment on attachment 552702 [details] [diff] [review]
Patch

Review of attachment 552702 [details] [diff] [review]:
-----------------------------------------------------------------

I have one big hangup with this patch, below. Also, make sure you update the docs at:
https://developer.mozilla.org/en/SpecialPowers

and this could probably use a simple test in test_SpecialPowersExtension:
http://mxr.mozilla.org/mozilla-central/source/testing/mochitest/tests/test_SpecialPowersExtension.html?force=1

::: testing/mochitest/specialpowers/content/specialpowers.js
@@ +390,5 @@
> +
> +  getFile: function(path) {
> +    var file = Components.classes["@mozilla.org/file/directory_service;1"]
> +               .getService(Components.interfaces.nsIProperties)
> +               .get("CurWorkD", Components.interfaces.nsIFile);

CurWorkD is probably $objdir/_tests/testing/mochitest in a local build, and $builddir/mochitest in a packaged build. I'm not sure that that's the best place to make paths relative to. I think I'd prefer either:
a) Relative to tests/ underneath that directory, so you'd wind up using getFile($relativesrcdir/file) or
b) Relative to the directory containing the current test, so you could just getFile("foo") for files in the same directory. This is probably more of a pain to handle (you might have to parse this.window.location out), but seems like the easiest for test authors to use.
Attachment #552702 - Flags: review?(ted.mielczarek) → review-
Assignee: khuey → nobody
You need to log in before you can comment on or make changes to this bug.