Apparently using nsIFile is deprecated, so its usage will need to be replaced with whatever is appropriate. I'm seeing the following warning in logcat: [JavaScript Warning: "Use of nsIFile in content process is deprecated." {file: "jar:file:///system/b2g/omni.ja!/components/DirectoryProvider.js" line: 81}] when launching the settings app.

JS Stack: > 0 dp_getFile(prop = \"coreAppsDir\", persistent = [object XPCOutParam]) [\"jar:file:///system/b2g/omni.ja!/components/DirectoryProvider.js\":81] > 1 FileUtils_getDir(key = \"coreAppsDir\", pathArray = webapps, shouldCreate = false) [\"resource://gre/modules/FileUtils.jsm\":63] > 2 getCoreAppsBasePath() [\"resource://gre/modules/AppsUtils.jsm\":324] > 3 getAppInfo(aApps = [object Object], aAppId = \"settings.gaiamobile.org\") [\"resource://gre/modules/AppsUtils.jsm\":344] > 4 getAppInfo(aAppId = \"settings.gaiamobile.org\") [\"resource://gre/modules/AppsServiceChild.jsm\":421] > 5 getAppInfo(aAppId = \"settings.gaiamobile.org\") [\"jar:file:///system/b2g/omni.ja!/components/AppsService.js\":112]

DirectoryProvider.js:81 https://dxr.mozilla.org/mozilla-central/source/b2g/components/DirectoryProvider.js#81 AppsUtils.jsm:324 https://dxr.mozilla.org/mozilla-central/source/dom/apps/AppsUtils.jsm#323-330 AppsUtils.jsm:344 https://dxr.mozilla.org/mozilla-central/source/dom/apps/AppsUtils.jsm#345-347 AppsServiceChild.jsm:421 https://dxr.mozilla.org/mozilla-central/source/dom/apps/AppsServiceChild.jsm#420-422 AppsService.js: 244 https://dxr.mozilla.org/mozilla-central/source/dom/apps/AppsService.js?from=AppsService.js#110-113

The nsIFile deprecation warning was, I think, intended more for add-on authors. What we're doing with app: URIs, where we construct a filesystem path in the child and then send it to the parent for validation, is what we'd encourage add-on authors *not* to do — it's too easy to get the validation wrong, and the code would probably be cleaner with only one place needing to care about what the filesystem paths look like. But redesigning the app: and remoteopenfile: stuff to just send the app domain over IPC is work that seems unlikely to happen. The other thing is that, on desktop, chrome: and resource: URIs can have a similar role, and those currently just expand to jar:file:/// and get opened directly in the child. So they're in a strictly worse state as far as sandboxing, but if nsIFile is used only in C++ rather than JS, they won't cause this warning. So from the B2G side this probably isn't anything to worry about, but from the e10s side is worth keeping in mind as we figure out what to do about nsIFile.

Jed, I guess my question is whether this warning is relevant on b2g. If it isn't, we should disable it for b2g. Does b2g have a goal of limiting file system access from the child process?

b2g severely limits write access to child processes through the OS. For example, the ONLY place that a child process gets write access to is /data/local/tmp All of the places that a child process gets read access to (other than /data/local/tmp) are from read-only filesystems (like /system). The exception to all of this is in a few special cases the parent process will open a file for the child and pass it a file descriptor (we do this for the camera app). Even these are slowly disappearing.

OK, but is this warning useful on b2g? Is there an eventual plan to eliminate all file access?

I don't know. The error is fundamentally happening due to this check: https://dxr.mozilla.org/mozilla-central/source/dom/apps/AppsUtils.jsm#346 So if that check can somehow be rewritten to not require file access, then this warning would go away. The problem is that the nsIDirectoryServiceProvider returns an nsIFile, even though it just wants the directory name. I don't see the warning as beneficial on b2g, unless it can be filtered so that it only happens from content and not from chrome.

(In reply to Bill McCloskey (:billm) from comment #6) > OK, but is this warning useful on b2g? Is there an eventual plan to > eliminate all file access? We'll probably never be able to eliminate *all* filesystem access from content processes, since that includes code in system libraries and proprietary drivers that we call. Bug 930258 plans to restrict filesystem access by brokering what's left of it through an unsandboxed process with a whitelist policy. There's a followup meta-bug, bug 1121295, collecting the whitelist entries (and not quite complete at the moment). The work-in-progress filesystem policy for B2G is fairly restrictive: most of it is read-only (exceptions: some device files, maybe logging, and the profiler unless that's fixed first), and the only cases where an entire subtree is allowed are for system libraries and fonts.

(In reply to Dave Hylands [:dhylands] from comment #7) > The error is fundamentally happening due to this check: > https://dxr.mozilla.org/mozilla-central/source/dom/apps/AppsUtils.jsm#346 Maybe a tangent, but won't that always be false on eng builds, which store everything in /data/local? Surely there's a better way to do that. > I don't see the warning as beneficial on b2g, unless it can be filtered so > that it only happens from content and not from chrome. I didn't think there was any way for content to access an nsIFile. (Or any other XPCOM interface? Is everything in the DOM using WebIDL these days?) (In reply to Bill McCloskey (:billm) from comment #6) > OK, but is this warning useful on b2g? I'd tend to think not.

(In reply to Jed Davis [:jld] {UTC-7} from comment #9) > (In reply to Dave Hylands [:dhylands] from comment #7) > > The error is fundamentally happening due to this check: > > https://dxr.mozilla.org/mozilla-central/source/dom/apps/AppsUtils.jsm#346 > > Maybe a tangent, but won't that always be false on eng builds, which store > everything in /data/local? Surely there's a better way to do that. Even eng builds have the default apps in /system/b2g/webapps iirc. > > I don't see the warning as beneficial on b2g, unless it can be filtered so > > that it only happens from content and not from chrome. > > I didn't think there was any way for content to access an nsIFile. (Or any > other XPCOM interface? Is everything in the DOM using WebIDL these days?) There's no direct access possible from content, only chrome js. > (In reply to Bill McCloskey (:billm) from comment #6) > > OK, but is this warning useful on b2g? > > I'd tend to think not. I agree. Also, I hope to remove the need for the app:// protocol sometimes later this year as part of v3, so let's not put too much effort in fixing that.

(In reply to Fabrice Desré [:fabrice] from comment #10) > Even eng builds have the default apps in /system/b2g/webapps iirc. https://github.com/mozilla-b2g/gaia/commit/1c2629edae59 says: > For eng (default) builds, use /data/local/webapps > for user (production) builds, use /system/b2g/webapps Empirically, I have three different devices where /system/b2g/webapps doesn't exist.

(In reply to Jed Davis [:jld] {UTC-7} from comment #11) > (In reply to Fabrice Desré [:fabrice] from comment #10) > > Even eng builds have the default apps in /system/b2g/webapps iirc. > > https://github.com/mozilla-b2g/gaia/commit/1c2629edae59 says: > > > For eng (default) builds, use /data/local/webapps > > for user (production) builds, use /system/b2g/webapps authored on Sep 9, 2012 I still thinks that we changed that since, but that doesn't really matter anyway. > Empirically, I have three different devices where /system/b2g/webapps > doesn't exist. Which versions are they running?

I built a flame-kk eng build today using the latest master, and there is no /system/b2g/webapps directory. See: https://github.com/mozilla-b2g/gaia/blob/master/Android.mk#L25-L28

(In reply to Fabrice Desré [:fabrice] from comment #12) > (In reply to Jed Davis [:jld] {UTC-7} from comment #11) > > https://github.com/mozilla-b2g/gaia/commit/1c2629edae59 says: > > > > > For eng (default) builds, use /data/local/webapps > > > for user (production) builds, use /system/b2g/webapps > > authored on Sep 9, 2012 I found it by annotating the current Android.mk in the places where it sets GAIA_APP_INSTALL_{PARENT,PATH}. But, looking at the history more, I've found bug 945903 — maybe the current behavior is a bug that was introduced more recently? > > Empirically, I have three different devices where /system/b2g/webapps > > doesn't exist. > > Which versions are they running? Two on master (flame-kk, emulator-x86-kk), one on v2.2 (nexus5-l). All of them are the result of a fresh build.sh/flash.sh.

Firefox OS is not being worked on