938475 - No way for other apps to determine what profile is running

Status: RESOLVED WONTFIX

(Toolkit :: Startup and Profile System, defect)

Description

[Jerry Krinock]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9) AppleWebKit/537.71 (KHTML, like Gecko) Version/7.0 Safari/537.71

Steps to reproduce:

1. Create a Mac OS X app which is a companion to Firefox, for example, a bookmark manager.  The app has a Firefox extension which the user may install into a selected Firefox profile.

2.  Realize that the app needs to know which profile the user is running in before launching the extension installer.  This is because, if Firefox is not running in the intended profile, the extension would be installed into the wrong profile.

3.  Look for some API or other way to determine what profile Firefox is running in.


Actual results:

I found nothing documented in Firefox to help with this.  I did find this blog post by Jonathan Griffin:

http://jagriffin.wordpress.com/2011/01/11/profilemanager-1-0_beta1/

and in his source code, I learned the tidbit that, when Firefox is running in a profile, there is a folder named .parentlock in that folder and it is locked with the unix flock (advisory file lock) system.  So you can get the answer by checking for this file and its flock state.  But this is a Firefox implementation detail which is not documented.


Expected results:

There should be a documented, supported way for other applications to determine which profile Firefox is currently running in.

Comment 1

[Steven Michaud [:smichaud] (Retired)]

This rings a bell.

I vaguely remember a discussion about finding a better way for an app to know which version of Firefox to launch and run in (when, as can happen, there are many different copies of Firefox installed).  I believe we decided that the app should have (in its own stub executable?) a full path to the copy of Firefox that "installed" it, but I'm not sure if this was actually done.

Later I'll see if I can find where this was discussed (I think it was in a Bugzilla bug).

I'm not sure this will be helpful, though, because I don't really understand (from the description) what this bug is about.

Why do you need to know "what profile Firefox is running in"?  And what exactly does this mean?

Do you need to know the values of certain Firefox settings (in the "current profile")?

Comment 2

[Steven Michaud [:smichaud] (Retired)]

> Create a Mac OS X app which is a companion to Firefox, for example, a bookmark manager.

It's also not clear what this means.

In comment #1 I was talking about "web apps" (https://developer.mozilla.org/en-US/Apps/Quickstart/Build/Intro_to_open_web_apps).  Is this what you're trying to make?  If not, maybe it should be.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

This is almost certainly not a Mac-specific problem.  It will presumably also arise on other platforms (like Windows and Linux).

Comment 4

[Steven Michaud [:smichaud] (Retired)]

> There should be a documented, supported way for other applications
> to determine which profile Firefox is currently running in.

I strongly suspect we shouldn't have such an API.

But I don't know who should decide the matter, or how this bug should
be categorized.  Liz, do you have any ideas?

Comment 5

[Jerry Krinock]

• In answer to: "Why do you need to know 'what profile Firefox is running in'?"

My application imports bookmarks from and exports bookmarks to Firefox via a Firefox extension.  Because Firefox supports multiple user profiles, my application does also.

Say that user has two Firefox user profiles "A" and "B", and that the user currently has Firefox running in profile "A".  New bookmarks arrive from a server that the user has set up to sync to Firefox profile "B".  If my app pushed these bookmarks over to my Firefox extension without first checking to see what profile Firefox was running in, these bookmarks would end up in profile "A", instead of profile "B" as expected.  Now, you might say that there is a solution to this, that *if* the bookmark manager's companion Firefox extension was installed in profile "A", the bookmark manager app could ask its Firefox extension to execute this bit of JavaScript:

Components.classes["@mozilla.org/file/directory_service;1"].getService(Components.interfaces.nsIProperties).get("ProfD", Components.interfaces.nsIFile).path

and from the result of that could reverse-engineer which profile Firefox is running in.  But that does not help if the extension is not installed in Profile "A".  Instead, it could cause the bookmarks manager app to open its Firefox extension installer and prompt the user to install the extension into Profile "A", and THEN push the bookmarks into the wrong user profile :))

There is a brute force solution to this problem.  The bookmarks manager could display a dialog upon first launch, saying "This app requires that its Firefox extension be installed into all Firefox profiles, and you must do that now".  But that is definitely a one-star user experience; at least for a Mac app, people would rip me to shreds.  And then what if they create another Firefox user profile two months later.  Ooops.

The robust solution is for the bookmarks manager app to be able to look from the outside, independent of its Firefox extension, and be able to determine what profile Firefox is running in.  I do this now by checking the file lock state of .parentlock, as explained in my original description.  It works perfectly, but is an undocumented side effect and therefore subject to breakage.
  

• In answer to: "Exactly what does that mean?"

Firefox supports multiple user profiles on the same computer user account.  See [1].  Note that Firefox may be running in only one profile at a time.


• Further explanation of: "Create a Mac OS X app which is a companion to Firefox, for example, a bookmark manager."  Could this be a web app?

I mean a native Mac OS X app written in Objective-C and Cocoa.  For an example, see [2].  No, this cannot be a web app because only on the so-called "desktop" can I access the bookmarks of Firefox, Chrome and Safari.

* * *

Yes, anyone trying to build a bookmarks manager on Windows or Linux would have the same problem.

This is in fact a native-app, OS-level problem, and the ideal solution would be platform-dependent, just as the existing command-line profile incantations are. [3]  In Mac OS X, the ideal solution would be to implement an AppleScript property.  This would make the information accessible to power users too.  But since Firefox does not implement any AppleScriptability at all, you're probably not going to go there. Just documenting the .parentlock kludge currently used by myself and Jonathan Griffin's Profile Manager would be acceptable, although other developers would appreciate something a little more straightforward such as, oh, writing a string to a file at a designated path.

Hey, I just noticed something else.  In Mozilla's Profile Manager documentation [1], there is a note that the command-line profile incantations have/may/be deprecated in favor of the ProfileManager app, and if you follow the link to the ProfileManager app, you see that it is the ProfileManager written by Jonathan Griffin, which uses the .parentlock kludge.  So now there is an official Mozilla project using the .parentlock kludge, so the proof that this problem exists and needs an officially supported solution is in your own code :)

Thanks,

Jerry

P.S.  For your information, I have the same problem with Google Chrome, although the kludge which I devised to solve that problem is even more complicated, because Chrome can run multiple profiles simultaneously in different windows.  Supporting multiple profiles in an app cuts into many objects, and facets are exposed in surprising places.

[1] https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
[2] http://sheepsystems.com/bookmacster
[3] Refer to [1], and note that there are separate sections for "Starting Profile Manager in…" "…Windows", "…Linux", "…Mac OS X".

Comment 6

[Steven Michaud [:smichaud] (Retired)]

Thanks for the detailed response.

But I frankly need to think about all this a bit :-)  Even before I decide who to try to pass this along to.

I'll try to come up with a reasoned response (possibly including some suggestions for alternate designs) by early next week.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #5)

> Hey, I just noticed something else.  In Mozilla's Profile Manager
> documentation [1], there is a note that the command-line profile
> incantations have/may/be deprecated in favor of the ProfileManager
> app, and if you follow the link to the ProfileManager app, you see
> that it is the ProfileManager written by Jonathan Griffin ...

I don't see this at
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles.
Is it in one of the pages referenced from that page?  Has the page
changed?

Comment 8

[Steven Michaud [:smichaud] (Retired)]

I've taken a break and a rest, and carefully re-read what you have to say in comment #5.  But I still have the same gut feeling I had before -- we shouldn't provide a formal API for other apps to query which profile Firefox is using, and we shouldn't promise not to break the informal kluge that you (and others) are now using.

What you're asking is for us to "externalize" part of what are currently Firefox's internal workings.  The correct way to do this is to provide a formal (and public) API, on all platforms.  But that would be quite a lot of work, and I don't think your use case justifies it -- especially given that very few other extensions will want or need to be this "intrusive".

I'm also a bit concerned about the security implications.  We (like other browsers) go to some trouble to prevent web content from having "unauthorized" access to even the current profile (never mind other profiles).  Extensions are more privileged, but even they don't (apparently) have access, by themselves, to other profiles.  It's true that a user with admin privileges needs to allow your app to be installed.  But a formal API would (and should) be available for anyone to use -- including less scrupulous apps.

Well then, what about promising not to break your kluge(s)?  I *really* don't think we should go there.  If we did that at all often, things would quickly get impossibly messy.

All this said, we can't really stop you from using your kluges.  Nor do I think we should even try.  But I think we should leave them "undocumented" -- which means they may break without warning, and you will need to watch out for that.  I'm not unsympathetic to your position -- I'm the author of an app that made heavy use of undocumented APIs and behavior (the Java Embedding Plugin, http://javaplugin.sourceforge.net/).  But I knew from the beginning that Apple would never document the APIs I used, and knowingly took the risk they might change without warning.

This is what *I* think, and also what I think Mozilla should do.  But let me try to find someone to CC on this bug who knows more about extensions that I do.

Comment 9

[Liz Henry (:lizzard) (privacy/fingerprinting team)]

Steven, my best guess would have been passing it on to the folks who work on Profile Manager, but now I'm not sure of that. Your points about security and what we want Firefox to do are interesting!

jgriffin, your post got cited here as well as your work on the profile manager a while back, so I'm checking to see if you have an opinion on this.

Comment 10

[Jonathan Griffin (:jgriffin)]

The standalone Profile Manager project was basically abandoned, after a related project to remove the built-in profile manager from Firefox was.  But yes, it used an ugly kludge to determine what profile was active.

I can certainly see the use case for implementing a more reliable way of allowing third-party apps to detect which profile is currently in use; whether it's enough to justify the necessary coding is another question.

I'm cc'ing bsmedberg who might have an opinion.

Comment 11

[Benjamin Smedberg]

Indeed, we do not intend to expose the currently running profile as an API. If you have an extension installed into an app, you can of course expose that as an API yourself, and I would strongly recommend that instead of relying on parentlock implementation details.

Comment 12

[Jerry Krinock]

I agree, Ben.  If the extension is already installed, we can find out which profile is running.  The problem is when another app needs to install an extension into Firefox, into a specified profile.  Before opening the installer, the app should be able to verify that the current profile in Firefox, which is the profile into which the extension will be installed, is the specified profile.  

Use cases for apps installing extensions into Firefox are similar to those for apps installing extensions into Google Chrome.  Google Chrome supports "External Extensions" for this.  You can read about Chrome's External Extensions feature here: https://developer.chrome.com/extensions/external_extensions.