1236377 - Profile sharing when dual-booting, all add-ons disabled after OS switch

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[lordgravewish]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20151216175450

Steps to reproduce:

Setup dual-booting of two OSes (in my case, Windows 10 + Linux Mint 17.2) and install Firefox 43.
Create a Firefox profile under a shared drive, and configure Firefox on both OSes to use that profile.
Boot one of them (doesn't matter which), open Firefox, install/enable some add-ons. [Optionally restart Firefox to check that addons are enabled and working.]
Reboot to the other OS. Launch Firefox. [All add-ons have been automatically disabled.]


Actual results:

When switching OSes, the add-on status (enabled or disabled) is not kept. Add-ons must be manually re-enabled.


Expected results:

Add-ons enabled under one OS would stay enabled under the other OS.

[The same behaviour Firefox 42 and earlier have had for years. Only after upgrading to Firefox 43 did this issue appear.]

Comment 1

[Liz Henry (:lizzard) (relman/hg->git project)]

Jorge, do you know what might have changed here (or can you pass this bug on to someone who might take a look at it?)

Comment 2

[Jorge Villalobos [:jorgev] (he/him)]

Maybe Mossop knows? I'm surprised that it's possible to share profiles between different operating systems like that. My best guess is that the add-ons storage doesn't work correctly in that case. Could be related to signing, but I'm not sure.

Comment 3

[Liz Henry (:lizzard) (relman/hg->git project)]

I was also surprised this ever worked but I had a look online and people seem to have been doing this since 2006 or maybe before that!

Comment 4

[lordgravewish]

It has worked since at least 2010, as I've been using this method since then on my dual-booting systems without any issues (I have even once shared a profile folder between a host and a VM without any issues as long as you never opened Firefox on both simultaneously). It's also always been possible to copy the Firefox profile to a different computer (running different hardware/OS) and just use it as if nothing changed (sort of like a manual synchronization process), or use Dropbox/etc to synchronize the profile folder. I thought this was actually an intended feature?

Only since I upgraded to Firefox 43 did this issue show up. FF43 must've change something to do with add-ons (for example, now they must be signed - but I have tried setting xpinstall.signatures.required to false does not solve the problem). At least another user on reddit reported the same problem starting in FF43 with the Mageia Linux distribution and Windows 7, so I decided to report it here as a bug.

Comment 5

[Dave Townsend [:mossop]]

This isn't something that has ever been really supported but it has been working for add-ons since we had to support Fennec moving the profile around on the phone. I wouldn't be surprised if there are other bugs for other parts of the browser related to doing this so it isn't a high priority to fix.

That said it was probably broken by bug 1192921 and I'm not sure why so there might be something else broken here. Enabling extensions.logging.enabled in about:config, then doing the OS switch that disabled the add-ons and getting the information logged to the browser console on startup would be useful to help diagnose this.

Comment 6

[lordgravewish]

Attachment: 1_windows_startup.log

Comment 7

[lordgravewish]

Attachment: 2_linux_startup.log

Comment 8

[lordgravewish]

Attachment: 3_windows_startup_after_linux.log

Comment 9

[lordgravewish]

Attachment: 4_windows_startup_second_time_after_linux.log

Comment 10

[lordgravewish]

>Enabling extensions.logging.enabled in about:config, then doing the OS switch that disabled the add-ons and getting the information logged to the browser console on startup would be useful to help diagnose this.

I just did this. First, I booted into windows, and started Firefox. I then enabled all the extensions, and rebooted Firefox (Log 1: 1_windows_startup.log). Then, I rebooted into Linux, and started Firefox again - addons had been disabled but could be manually enabled without restarting (Log 2: 2_linux_startup.log). I then enabled all addons again, and rebooted back into Windows. I then started Firefox, all addons were disabled and the add-on manager wouldn't work - it was stuck "loading" with that rotating circle thing (Log 3: 3_windows_startup_after_linux.log - notice the add-on manager crashes with some kind of access denied error). I then rebooted Firefox on Windows, and while add-ons were still disabled, the Add-on manager worked and they could be re-enabled (Log 4: 4_windows_startup_second_time_after_linux.log).

The aforementioned log files have been attached to this bug (hopefully I did everything correctly? Not exactly familiar with Bugzilla, so sorry if I made a mistake somewhere in the process). Hopefully this helps to diagnose the problem. Both OSes are running Firefox 43.0 x64 (the Windows version was downloaded from the Mozilla website, while the Linux version came from the Mint repositories).

Comment 11

[lordgravewish]

Sorry, I made a mistake. I meant to state they are both running Firefox 43.0.1

Comment 12

[Dave Townsend [:mossop]]

(In reply to lordgravewish from comment #10)
> I then enabled all addons again,
> and rebooted back into Windows. I then started Firefox, all addons were
> disabled and the add-on manager wouldn't work - it was stuck "loading" with
> that rotating circle thing (Log 3: 3_windows_startup_after_linux.log -
> notice the add-on manager crashes with some kind of access denied error).

This is quite strange. Does that happen on the first startup when switching back to Linux too? Did that happen in Firefox 42?

Comment 13

[lordgravewish]

>This is quite strange. Does that happen on the first startup when switching back to Linux too? Did that happen in Firefox 42?

As far as I've noticed, it only happens (*always* happens) whenever switching from Linux to Windows (I need to restart Firefox to be able to re-enable addons). When doing Windows->Linux the addons-manager interface always works immediately (without starting it up a second time).

On Firefox 42, everything worked fine on first boot on both OSes (addons would be enabled, and work fine, immediately after starting Firefox even after doing an OS switch).

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

Bug 433196 has some recent comments about issues with dual-boot profiles and initialization. Sounds like these reports may be related.

Comment 15

[Liz Henry (:lizzard) (relman/hg->git project)]

Noting support issues in this bug as well. 

https://support.mozilla.org/en-US/questions/1099842
https://support.mozilla.org/en-US/questions/1089646

Comment 16

[root]

Hello. I am the guy filing the support question. I can confirm everything the OP posted. In addition I have to say this occurs to me every time I change the OS, in both OS. If I just restart windows or linux (like running it for a second time), it doesn't happen.

Comment 18

[lordgravewish]

(In reply to Dave Townsend [:mossop] from comment #12)
> (In reply to lordgravewish from comment #10)
> > I then enabled all addons again,
> > and rebooted back into Windows. I then started Firefox, all addons were
> > disabled and the add-on manager wouldn't work - it was stuck "loading" with
> > that rotating circle thing (Log 3: 3_windows_startup_after_linux.log -
> > notice the add-on manager crashes with some kind of access denied error).
> 
> This is quite strange. Does that happen on the first startup when switching
> back to Linux too? Did that happen in Firefox 42?

I've been able to figure out more or less why this is happening. On Windows, I sandbox (using Sandboxie) a few important networked applications, like Firefox, Thunderbird, among others. I allow them full permissions on the profile folder, and read + "fake write" (it writes to a separate persistent "virtual filesystem" only that application sees) permissions everywhere else except for personal folders (not C:/Users, actual personal documents in non-system drives), other important application's profiles (no access at all), and system folders (read, but no write). Sandboxed applications are also not allowed privilege elevation through UAC, among other things. This is useful because if ever one of these applications become compromised, they can literally do no damage to the system (and I can always one-click "wipe changes") unless they break the sandbox, nor can they read my personal documents (let's be honest, it's not the end of the world if I have to format the system after an attack - I only really worry about someone grabbing all my personal information and me later being a victim of identity theft or something similar).

While I have multiple times (including before I created this report) disabled Sandboxie to check whether this problem might occur because of it, I had never noticed the add-on manager only crashes on first Windows startup if Sandboxie is enabled.

Now, I am wondering, because this never happened with FF42 and earlier - what exactly is Firefox trying to access? It should have "fake write" permissions almost anywhere - the sandboxed virtual filesystem is transparent to the applications. I checked the changelog of the virtual filesystem and there's literally nothing remarkable (AppData, Temporary files, etc). This means it's trying to write/read somewhere it doesn't have permissions (system folders, or my personal documents outside C:/Users).

Bug 1192921 mentions the creation of a system install location for add-ons since FF43, but I can't find a mention of what path exactly that would be. My assumption is that it's in one of the system folders I disallow access to. I am also thinking whether the problem is that this system directory is not shared between both OSes, and there's some important information being stored there (for example, whether the browser has been initialized since the last update). Maybe sym-linking this "system add-ons folder" would solve the problem?

Comment 19

[Dave Townsend [:mossop]]

(In reply to lordgravewish from comment #18)
> (In reply to Dave Townsend [:mossop] from comment #12)
> > (In reply to lordgravewish from comment #10)
> > > I then enabled all addons again,
> > > and rebooted back into Windows. I then started Firefox, all addons were
> > > disabled and the add-on manager wouldn't work - it was stuck "loading" with
> > > that rotating circle thing (Log 3: 3_windows_startup_after_linux.log -
> > > notice the add-on manager crashes with some kind of access denied error).
> > 
> > This is quite strange. Does that happen on the first startup when switching
> > back to Linux too? Did that happen in Firefox 42?
> 
> I've been able to figure out more or less why this is happening. On Windows,
> I sandbox (using Sandboxie) a few important networked applications, like
> Firefox, Thunderbird, among others. I allow them full permissions on the
> profile folder, and read + "fake write" (it writes to a separate persistent
> "virtual filesystem" only that application sees) permissions everywhere else
> except for personal folders (not C:/Users, actual personal documents in
> non-system drives), other important application's profiles (no access at
> all), and system folders (read, but no write). Sandboxed applications are
> also not allowed privilege elevation through UAC, among other things. This
> is useful because if ever one of these applications become compromised, they
> can literally do no damage to the system (and I can always one-click "wipe
> changes") unless they break the sandbox, nor can they read my personal
> documents (let's be honest, it's not the end of the world if I have to
> format the system after an attack - I only really worry about someone
> grabbing all my personal information and me later being a victim of identity
> theft or something similar).
> 
> While I have multiple times (including before I created this report)
> disabled Sandboxie to check whether this problem might occur because of it,
> I had never noticed the add-on manager only crashes on first Windows startup
> if Sandboxie is enabled.

Ok, so if the problem still occurs without sandboxie enabled then we should focus on that in this bug. If you want to file a different bug to look into the sandboxie issue then feel free.

It might be useful to redo the steps you did previously but with sandboxie disabled to get the right logs for this issue just in case the crash that sandboxie causes is causing a change there.

> Now, I am wondering, because this never happened with FF42 and earlier -
> what exactly is Firefox trying to access? It should have "fake write"
> permissions almost anywhere - the sandboxed virtual filesystem is
> transparent to the applications. I checked the changelog of the virtual
> filesystem and there's literally nothing remarkable (AppData, Temporary
> files, etc). This means it's trying to write/read somewhere it doesn't have
> permissions (system folders, or my personal documents outside C:/Users).
> 
> Bug 1192921 mentions the creation of a system install location for add-ons
> since FF43, but I can't find a mention of what path exactly that would be.
> My assumption is that it's in one of the system folders I disallow access
> to. I am also thinking whether the problem is that this system directory is
> not shared between both OSes, and there's some important information being
> stored there (for example, whether the browser has been initialized since
> the last update). Maybe sym-linking this "system add-ons folder" would solve
> the problem?

There are some system add-ons read from the application directory (no writing though) and a new directory in the profile that gets written to.

Comment 20

[Muphrid]

Hello, I've been doing this (dual boot windows and ubuntu with the same firefox profile) for years, at least since 2011 when I started using ubuntu regularly.  I continue to use the firefox profile created from my windows user account (residing on an NTFS partition) from ubuntu. This requires no special permissions, other than what is necessary for ubuntu to read and write to NTFS partitions.

What other information is needed to help track down this issue?  What more can be done to encourage someone to take a look at this issue?

Comment 21

[Dave Townsend [:mossop]]

(In reply to Muphrid from comment #20)
> Hello, I've been doing this (dual boot windows and ubuntu with the same
> firefox profile) for years, at least since 2011 when I started using ubuntu
> regularly.  I continue to use the firefox profile created from my windows
> user account (residing on an NTFS partition) from ubuntu. This requires no
> special permissions, other than what is necessary for ubuntu to read and
> write to NTFS partitions.
> 
> What other information is needed to help track down this issue?  What more
> can be done to encourage someone to take a look at this issue?

Unless you're willing to dig into the code and narrow down what is happening there probably isn't a lot you can do to help at this point.

Comment 22

[root]

This is still active in FF44. So this is the new default now? Naive question maybe, but why isn't the person that broke this responsible for fixing it again? For me this bug is super bad, I have to manually activate 27 addons each time I reboot... Is there maybe any way to batch activate them at once, a script or the likes?

Comment 23

[Dave Townsend [:mossop]]

(In reply to root from comment #22)
> This is still active in FF44. So this is the new default now? Naive question
> maybe, but why isn't the person that broke this responsible for fixing it
> again? For me this bug is super bad, I have to manually activate 27 addons
> each time I reboot... Is there maybe any way to batch activate them at once,
> a script or the likes?

The problem is that this bug isn't a high priority. I know it affects you badly but the number of people that this bug affects is very small. Backing out the fix that probably caused it would break other things that affect more people so that isn't an option. I'm the one that probably broke it and I do feel responsible but so far I haven't found enough spare time to even try to narrow it down as I've been working on other bugs which have a much higher priority.

Comment 24

[root]

(In reply to Dave Townsend [:mossop] from comment #23)
> (In reply to root from comment #22)
> > This is still active in FF44. So this is the new default now? Naive question
> > maybe, but why isn't the person that broke this responsible for fixing it
> > again? For me this bug is super bad, I have to manually activate 27 addons
> > each time I reboot... Is there maybe any way to batch activate them at once,
> > a script or the likes?
> 
> The problem is that this bug isn't a high priority. I know it affects you
> badly but the number of people that this bug affects is very small. Backing
> out the fix that probably caused it would break other things that affect
> more people so that isn't an option. I'm the one that probably broke it and
> I do feel responsible but so far I haven't found enough spare time to even
> try to narrow it down as I've been working on other bugs which have a much
> higher priority.

David, thanks for the reply. Your work is appreciated, FF is an amazing product anyways.

Comment 25

[Dave Townsend [:mossop]]

Attachment: MozReview Request: Bug 1236377: Ignore invalid file descriptors when loading an add-ons database written by a different OS. r?rhelmer

nsIFile descriptors use OS specific formats so when trying to read them we have
to catch any failure if the database was written by a different OS. This leaves
the _sourceBundle undefined in only one case which is guaranteed to be during
startup since xpistate.descriptor for the add-on will also be incorrect and so
the full add-on scan will be triggered. That will spot the mismatch and update
the add-on in the database with the correct descriptor.

Review commit: https://reviewboard.mozilla.org/r/33315/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/33315/

Comment 26

[Dave Townsend [:mossop]]

Comment on attachment 8715045 [details]
MozReview Request: Bug 1236377: Ignore invalid file descriptors when loading an add-ons database written by a different OS. r?rhelmer

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/33315/diff/1-2/

Comment 27

[Dave Townsend [:mossop]]

Comment on attachment 8715045 [details]
MozReview Request: Bug 1236377: Ignore invalid file descriptors when loading an add-ons database written by a different OS. r?rhelmer

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/33315/diff/2-3/

Comment 28

[Robert Helmer [:rhelmer]]

Comment on attachment 8715045 [details]
MozReview Request: Bug 1236377: Ignore invalid file descriptors when loading an add-ons database written by a different OS. r?rhelmer

https://reviewboard.mozilla.org/r/33315/#review30507

::: toolkit/mozapps/extensions/test/xpcshell/xpcshell-shared.ini:310
(Diff revision 3)
> +skip-if = os == "mac" && debug

Hm is this because of this crash in the try run?

```
18:15:40 INFO - PROCESS | 5225 | \x07[5225] ###!!! ASSERTION: SetPersistentDescriptor was given bad data: 'Error', file /builds/slave/try-m64-d-00000000000000000000/build/src/xpcom/io/nsLocalFileUnix.cpp, line 1910
```

Is this an assert that's only in debug builds or something? I think it's fine to skip for now but should we file a followup to look at changing this in the platform?

Comment 29

[Dave Townsend [:mossop]]

https://reviewboard.mozilla.org/r/33315/#review30507

> Hm is this because of this crash in the try run?
> 
> ```
> 18:15:40 INFO - PROCESS | 5225 | \x07[5225] ###!!! ASSERTION: SetPersistentDescriptor was given bad data: 'Error', file /builds/slave/try-m64-d-00000000000000000000/build/src/xpcom/io/nsLocalFileUnix.cpp, line 1910
> ```
> 
> Is this an assert that's only in debug builds or something? I think it's fine to skip for now but should we file a followup to look at changing this in the platform?

Yeah I filed bug 1246231 already. We shouldn't be asserting there.

Comment 30

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/60c2eb5b8355

Comment 31

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/60c2eb5b8355

Comment 32

[Loic]

Could we have this patch in FF466 too? I saw another report with a user getting add-ons disabled on triple boot machine with profiles stored on partition shared by the 3 OSes.

Comment 33

[Tomas Kopal]

Seems Thunderbird having the same issue (at least in ver. 45.6.0, dual booting Win7 and Linux Mint). Can this fix be taken there as well? I was waiting for this to be picked up for a while, as this is a toolkit fix, which I understand is shared between the two, but so far the problem remains in TB. Or do I need to report it somehow separately?

Comment 34

[JP]

Issue has come back - FF57 requires re-enabling all add-ons after OS-change in multi-boot environments. Maybe bringing in relative paths and the '[ProfD]' variable from prefs.js into the add-on management would be a viable solution.

Comment 35

[Andrew Swan [:aswan]]

I haven't read through all the old comments but this isn't a scenario that we support.  Extensions can be stored in places other than the profile directory so we need to store absolute paths.  The supported way to handle this is to have separate profiles for each OS and use Firefox Sync to keep them synchronized with each other.

Comment 36

[rishel.nick]

Came here to confirm the issue has reappeared (FF59 Beta).

Comment 37

[rishel.nick]

For posterity, this seems to be fixed again in FF61.