Hi there,
I'm an addon developer and was trying to support portable with my addon.
I need a way to detect if the firefox my profile is running from is portable, can you please help me on how i can do this?
One way I thought of was searching the directory for profiles.ini, but if the user has non-portable firefox installed, and also portable firefox installed, this method will not work.
Thanks
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
As the Firefox included within Firefox Portable is unaltered (same build, appid, useragent, etc), there isn't really a way to tell. I'd have suggested a few ways, but each one is customizable by the end user and could change. For example, the specific plugins or profile folder in a specific location relative to firefox.exe, but the user can alter each of those. -no-remote use was another possibility, but again, some users turn that off so they can run local and portable Firefox at the same time. Can you check if a specific environment variable (within Windows, not Firefox) is set easily? If so, it's possible we can add that being set in the future.
Sometimes, the impossible can become possible, if you're awesome!
The -no-remote i understand, because my addon is based on that.
I'll look into that environment variable thing but I was hoping for cross platform solution. Si first I'll finish this investigation please: I had this idea: not all the special directory paths are updated properly in portable. So say in non-portable Keyword "abc" path should equal keyword "rawr" path. Now if they don't match then we know it's portable.
I'm investigating that, this is the csv (comma delimited) file of the spcial paths of a portable and non-portable installtion:
http://pastebin.com/31tkTA6V
Ideally I'm hoping for a solution that doesn't involve changing the way portable works right now. That's like even after my last resort.
Thanks for offering that though.
One reason I don't prefer that is, lots of China users reached out to me, they have a portable version themselves which is slightly different but basically the same one from here.
Other is, there's gotta be a way lol
Currently, there is no organization I know of in China working on legal portable apps. There are several that package Firefox illegally, though, many using our work without credit and in violation of the GPL. There's even one ripping off the PortableApps.com registered trademark and distributing illegally modified copies of Firefox Portable alongside hacked versions of Photoshop and the like.
You can only repackage Firefox with the trademarks intact with Mozilla's permission. Otherwise you have to rename it (Pale Moon, etc). We have Mozilla's permission to do Firefox Portable.
Sometimes, the impossible can become possible, if you're awesome!
Oh no way, thanks for letting me know about that. Thankfully if my addon works on FFportable here it works on all of those. So I can help out the users but with the intent to fix it for the legal version.
what do you think of the method to test GreD and CurWorkD to determine if portable or not?
Thanks man
update: i had some users compare their GreD and CurProcD and on some portabes they were they same, so this is not a reliable way.
My current last resort is:
By default the addon works like this:
It gets the current profile path
It opens profiles.ini at the expected path
-if not found, then obviously its protable
-if found though then:
--it looks for current profile path in that profiles ini
--if not found it assumes that it is a temporary profile (launched from Mozilla Profile Manager application: http://www.ghacks.net/2011/11/05/mozilla-profile-manager-final-released/) BUT I can make the assumption be it's portable because profile was not found and then work on other way to identify if the profile is a temporary profile
Ok I think I got it. I need more users to test it but this is what I'm thinking.
For a non-portable firefox the paths for keyword CurWorkD and GreD are equal.
What do you think man?
/////////CODE can run from scratchpad
var DSP = Cc["@mozilla.org/file/directory_service;1"].getService(Ci.nsIProperties);
/////My non-portable firefox:
alert(DSP.get('GreD', Ci.nsIFile).path); //C:\Program Files (x86)\Mozilla Firefox
alert(DSP.get('CurWorkD', Ci.nsIFile).path); //C:\Program Files (x86)\Mozilla Firefox
/////My portable firefox:
alert(DSP.get('GreD', Ci.nsIFile).path); //C:\Users\C71ZQW1\Desktop\FirefoxPortable\App\firefox
alert(DSP.get('CurWorkD', Ci.nsIFile).path); //C:\Users\C71ZQW1\Desktop\FirefoxPortable
edit: update: i had some users compare their GreD and CurProcD and on some portabes they were they same, so this is not a reliable way.
These aren't complete. Just some thoughts on possibilities.
I can't recall if you have access to Windows environment variables or not. If you do, you could see if the PROGRAMFILES environment variable is a part of the CurWorkD. That will detect about 99% of local installs as local. The portable one can't be installed to PROGRAMFILES (since UAC messes it up). But this would miss the users who install to a custom location. Unfortunately, I'd wager this would have too much overlap with your userbase.
One other possibility, if you can check for the existence of a file, to look for FirefoxPortable.exe either in CurWorkD or two directories above CurWorkD. Not that this still may not be accurate as a user can fun firefox.exe directly within Firefox Portable and it will operate in local mode.
Sometimes, the impossible can become possible, if you're awesome!
Thanks a lot man for those suggestions I'll keep investigating and will get back to you with my results.
I don't understand what you mean by access to windows variables. If i do get access to them, can i do the same for mac os x and linux? I'm looking for a cross os solution.
There don't exist any legal or maintained portable versions of Firefox for other operating systems. There was an unofficial one for Mac a couple years ago but it is long since abandoned.
Sometimes, the impossible can become possible, if you're awesome!
Oh no way! Ok thanks for that info.
Ok man I give up I can't find a way so i'm going with my last resort solution.
-It looks for profiles.ini in the special path of UAppData (portable does not update this special path properly so it is equivalent to the UAppData as if it as hard installed firefox)
--If not found than it is portable
--If found than it may be the users hard installed Firefox profiles.ini to verify this we do the below
---Profiles.ini is opened and it looks the path name of the profile in use
----If it is NOT found then it IS portable or temporary profile, to figure out difference go to next step
-----xpcom code tells me if its temporary or not (i havent worked this out yet)
----If it IS found than it is NOT portable
So what do you think? This should work consistently correct? Only time I see it failing is if the profile path is found in profiles.ini of the hard instaleld firefox, but I don't think anyone that uses a profile in portable would use it in hard installed firefox. What do you think?
Also I'm assumng that profiles.ini does not exist anywhere in portable installtion, this is correct assumption no? (my addon then force creates profiles.ini in CurWorkD special path, so after first install of addon I can just test CurWorkD if it has profiles.ini and then that tells me right away its portable.
Actually I think I got it!! Thanks to help from paa at stackoverflow.
I'll get CurWorkD and XREExeF. Then get XREExeF.parent.parent and if this path is equal to or descendent of CurWorkD than it is portable. What do you think? Is this reliable?
Code:
var CurWorkD = Services.dirsvc.get('CurWorkD', Ci.nsIFile);
var XREExeF = Services.dirsvc.get('XREExeF', Ci.nsIFile);
if (XREExeF.parent.parent.path.indexOf(CurWorkD.path) > -1) {
//is portable
} else {
//is hard install
}
Man it doesn't work. I found exceptions.
Ok man screw it. I thought about this, and in the future I plan to add a feature that will need lots of code to support portable. It's setting a defualt profile so on startup it starts with that profile first. Because portable doesn't support profiles.ini it will be totally different.
So I'm just going to create a seperate channel/addon release called ProfilistPortable.
Thanks man for trying to help out so much.
You've said your addon was asked to be made portable but how many people asked for it? From where I'm sitting, knowing 2nd, 3rd, etc. FF profiles can exist why are you going on with this? If I remember the start of the conversations right you came here because some (1, 2, 3, 10?) people asked for this. Where are they?
Wm
I'm not sure of the exact number but I have seen 8 different people posting about within a short time frame. I have active support of 3 users to help make this portable, that's more support than any other feature I got.
It's not that big a deal too me, it'll give me good stats on what portable software is out there, by look at that the stats page to see what os they are running.
What do you mean by "From where I'm sitting, knowing 2nd, 3rd, etc. FF profiles can exist why are you going on with this?"?
I know we can make them but you can't switch between them from browser interface and run them in parallel. It's a very hidden feature of firefox.