1339100 - Firefox does not open correctly from read-only filesystem (FileUtils.getFile() failure when checking for bundled blocklist)

Status: NEW

(Toolkit :: Add-ons Manager, defect, P3)

Description

[Mark Smith [:mcs]]

When I try to open Firefox directly from the dmg on OSX, the Add-on Manager fails to start up correctly which means no bundled add-ons load, the Tools|Add-ons interface is broken, etc. (this was first reported against Tor Browser, which relies on several important bundled extensions).

The root cause is a failure inside FileUtils.getFile() when the Add-on Manager tries to check for a bundled blocklist. In toolkit/mozapps/extensions/AddonManager.jsm, the following line within validateBlocklist() throws an NS_ERROR_FILE_READ_ONLY error:
 let appBlocklist = FileUtils.getFile(KEY_APPDIR, [FILE_BLOCKLIST]);
The right fix would be to modify FileUtils.getDir() to to correctly handle the "read only filesystem" case; if the directory exists, it should not return an error.

The corresponding Tor Browser bug is https://trac.torproject.org/projects/tor/ticket/21445.

Comment 1

[Mark Smith [:mcs]]

I forgot to mention that it is easiest to reproduce this with a new profile. You can also reset extensions.lastAppVersion to cause the problem to occur each time Firefox is opened. Here are some relevant messages that show up in the Browser Console:

11:32:10.773 1487003530772	addons.manager	ERROR	startup failed: [Exception... "Component returned failure code: 0x80520013 (NS_ERROR_FILE_READ_ONLY) [nsIFile.create]"  nsresult: "0x80520013 (NS_ERROR_FILE_READ_ONLY)"  location: "JS frame :: resource://gre/modules/FileUtils.jsm :: FileUtils_getDir :: line 70"  data: no] Stack trace: FileUtils_getDir()@resource://gre/modules/FileUtils.jsm:70 < FileUtils_getFile()@resource://gre/modules/FileUtils.jsm:42 < validateBlocklist()@resource://gre/modules/AddonManager.jsm:671 < startup()@resource://gre/modules/AddonManager.jsm:834 < startup()@resource://gre/modules/AddonManager.jsm:3129 < observe()@resource://gre/components/addonManager.js:65 1 Log.jsm:748

11:32:10.774 NS_ERROR_NOT_INITIALIZED: AddonManager is not initialized 1 AddonManager.jsm:1649

Comment 2

[:shell escalante]

verifying

Comment 3

[krupa raj [:krupa--use this to needinfo]]

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1307447

Comment 4

[Robert Helmer [:rhelmer]]

We suspect this is related to the permissions in the Tor DMG, since this works for us on release and the code hasn't changed between the last ESR and release. This might be an easy tweak to fix this in the meantime.

The underlying problem is that FileUtils.getFile() tries to create the path up to the file, which is pretty odd behavior - at the very least it should be optional. We should probably fix this as a separate bug since it's FileUtils and not really AddonManager specific.

Also - I believe there is already a bug on putting up an error message (and maybe refusing startup) if Firefox is run from the DMG, I'll track that down.

Comment 5

[Mark Smith [:mcs]]

This is not specific to Tor Browser. I can reproduce the problem every time with Firefox 51.0.1 on a macOS 10.12.3 system.

Steps to reproduce:
1. Set aside ~/Library/Application Support/Firefox or configure Firefox to prompt at startup for which profile to use.
2. Download and open https://download.mozilla.org/?product=firefox-51.0.1-SSL&os=osx&lang=en-US
3. Open the Add-on Manager window (Tools|Add-ons) and notice that most of the panels are missing.

To reproduce the problem using an existing profile, clear the extensions.lastAppVersion preference.

Comment 6

[Robert Helmer [:rhelmer]]

Hm, thanks. I'll try again, but I've been testing with 51.0.1 ... I think kmag also couldn't repro. I have tried both a new profile and also setting extensions.lastAppVersion and restarting.

I am on 10.11 FWIW but I don't think that's related since I do definitely see this with the Tor build using the same steps. 

Could you try setting extensions.logging.enabled to true and paste the results from the browser console? That should enable debug logging. Thanks!

Comment 7

[Kris Maglione [:kmag]]

As far as I can tell, this only happens with Tor Browser, and in that case it seems to be because the DMG is an ISO-8859 image, rather than HFS. I couldn't reproduce that error at all with the official Firefox 51 DMG.

Comment 8

[Robert Helmer [:rhelmer]]

The method I used was to launch with a new profile:

/Volumes/Firefox/Firefox.app/Contents/MacOS/firefox --profile bug1339100-profile

Launching the same way reproduces on TorBrowser 6.5 for me, but not Firefox 51.0.1

Comment 9

[Robert Helmer [:rhelmer]]

Here's what `mount` has to say on my system:

/dev/disk2s2 on /Volumes/Firefox (hfs, local, nodev, nosuid, read-only, noowners, quarantine, mounted by rhelmer)
/dev/disk3 on /Volumes/Tor Browser (cd9660, local, nodev, nosuid, read-only, noowners, quarantine, mounted by rhelmer)

Comment 10

[Mark Smith [:mcs]]

Interestingly, when I run Firefox 51.0.1 from the command line this problem does not occur. Double-clicking the Firefox.app icon within the Finder window does reproduce the problem. I assume the difference is Apple's App Translocation feature. When I open Firefox via the Finder it is actually running from here:
 /var/folders/7j/956llh2d2ng4npmxwjc664sc0000gn/T/AppTranslocation/DA4414AE-784C-4DBA-88D3-7316D581B03F/d/Firefox.app/Contents/MacOS/firefox

So maybe Sierra is required to reproduce this bug.

I also ran with extensions.logging.enabled = true but that produced only a couple of additional log messages:

1488377882841	addons.manager	DEBUG	Application has been upgraded
1488377882841	addons.manager	ERROR	startup failed: [Exception... "Component returned failure code: 0x80520013 (NS_ERROR_FILE_READ_ONLY) [nsIFile.create]"  nsresult: "0x80520013 (NS_ERROR_FILE_READ_ONLY)"  location: "JS frame :: resource://gre/modules/FileUtils.jsm :: FileUtils_getDir :: line 70"  data: no] Stack trace: FileUtils_getDir()@resource://gre/modules/FileUtils.jsm:70 < FileUtils_getFile()@resource://gre/modules/FileUtils.jsm:42 < AddonManagerInternal.validateBlocklist()@resource://gre/modules/AddonManager.jsm:698 < AddonManagerInternal.startup()@resource://gre/modules/AddonManager.jsm:866 < this.AddonManagerPrivate.startup()@resource://gre/modules/AddonManager.jsm:3016 < amManager.prototype.observe()@resource://gre/components/addonManager.js:71  Log.jsm:753
1488377882842	addons.manager	DEBUG	Completed startup sequence
NS_ERROR_NOT_INITIALIZED: AddonManager is not initialized  AddonManager.jsm:1673
1488377882929	Toolkit.Telemetry	ERROR	TelemetryEnvironment::EnvironmentCache - error while initializing: TypeError: gShutdownBarrier is null (resource://gre/modules/AddonManager.jsm:3643:5) JS Stack trace: get [e-mail]:3643:5 < [e-mail]:426:7 < [e-mail]:766:11 < [e-mail]:60:26 < get [e-mail]:67:12 < [e-mail]:41:11 < [e-mail]:31:5  Log.jsm:753