User Agent: Mozilla/5.0 (Windows NT 6.0; rv:9.0.1) Gecko/20100101 Aurora9/9.0.1
Build ID: 20111220165912
Steps to reproduce:
There is a problem since Firefox 11 (12, 13 too)
I edited the application.ini for create separate profil.
It works for Firefox =< 10.
C:\Users\...\AppData\Roaming\Mozilla\Aurora10 (or C:\Documents and Settings\...\Application Data\Mozilla\Aurora10) works
It use the simple Firefox profil and not for Aurora11 / Aurora12 / Aurora13
C:\Users\...\AppData\Roaming\Mozilla\Aurora11 (or C:\Documents and Settings\...\Application Data\Mozilla\Aurora11) does not work
C:\Users\...\AppData\Roaming\Mozilla\Aurora12 (or C:\Documents and Settings\...\Application Data\Mozilla\Aurora12) does not work
C:\Users\...\AppData\Roaming\Mozilla\Aurora13 (or C:\Documents and Settings\...\Application Data\Mozilla\Aurora13) does not work
It must use the profil for Aurora11 / Aurora12 / Aurora13 and not for Firefox, it works for all version =< 10.
application.ini for Aurora11
C:\Users\...\AppData\Roaming\Mozilla\Aurora11 (or C:\Documents and Settings\...\Application Data\Mozilla\Aurora11) must work.
application.ini for Aurora12
C:\Users\...\AppData\Roaming\Mozilla\Aurora12 (or C:\Documents and Settings\...\Application Data\Mozilla\Aurora12) must work.
application.ini for Aurora13
C:\Users\...\AppData\Roaming\Mozilla\Aurora13 (or C:\Documents and Settings\...\Application Data\Mozilla\Aurora13) must work.
Have you tried using override.ini instead of application.ini? You may need to add an argument -override <path/to/override file> to get it to work.
application.ini was removed by default in bug 686466, but I believe override.ini was implemented in bug 407559.
Based on my reading of the file, the only thing that is read from the default override.ini is the profile migrator.
Otherwise override.ini must be specified by command line.
With the removal of application.ini, maybe override.ini should be read by default now?
There is not override.ini in the install folder and it is not for migration... It is for use in the same time.
I have several profils:
Aurora36 and install: C:\Program Files\Aurora36
Aurora4 and install: C:\Program Files\Aurora4
Aurora5 and install: C:\Program Files\Aurora5
Aurora6 and install: C:\Program Files\Aurora6
Aurora7 and install: C:\Program Files\Aurora7
Aurora8 and install: C:\Program Files\Aurora8
Aurora9 and install: C:\Program Files\Aurora9
Aurora10 and install: C:\Program Files\Aurora10
Aurora11 and install: C:\Program Files\Aurora11
Aurora12 and install: C:\Program Files\Aurora12
Aurora13 and install: C:\Program Files\Aurora13
application.ini works for:
Application.ini doesn't work anymore.
You have to use override.ini and specify it via a command line parameter.
How I can use override.ini ?
Put the same content as you did in Application.ini in override.ini
Invoke Firefox with
/INI=[PATH to new override.ini]
We create a customized firefox install for use an custom internal web application client. (lots of customizations). Since Firefox 11 our build doesn't work because it shares the profile with an already installed version of firefox. We were changing the vender and name in application.ini and setting
useragent.compatMode.firefox = true;
I don't want to have to invoke the app with a parameter. What do I need to change in the zipped install file to get this working again.
> I don't want to have to invoke the app with a parameter. What do I need to change in the zipped install file to get this working again.
Unfortunately it's simply not possible without recompiling Firefox.
Mozilla broke a pretty important feature and refuses to admit it is broke.
I can't get the /INI parameter to work when I try to point it at the application.ini or override.ini file. It still uses the firefox profile instead of the custom vendor/name profile. I tried using the full path with and without quotes. What am I missing?
Here is the shorcut command line I'm using that doesn't work.
"C:\Program Files (x86)\SquareTwo Financial\Eagle_dev\firefox.exe" /INI="C:\Program Files (x86)\SquareTwo Financial\Eagle_dev\override.ini"
I tried this but it causes an application crash
"C:\Program Files (x86)\[installdir]\firefox.exe" -override override.ini
I got it to recognize the Application.ini file with this command line
"C:\[InstallDir]\firefox.exe" -app "C:\[InstallDir]\Application.ini"
But I'm still looking for some way to configure this without using a command line parameter.
Don, what's the problem with the commandline parameter?
If you're bundling an application (and maybe renaming the executable), you shouldn't have to add a command line parameter.
Yes, we are bundling the application and renaming the executable but firefox 11 doesn't recognize the application.ini without using a command line parameter.
It just makes for a cleaner installation without needing a command line parameter.
If our users were to click on the executable or create a new shortcut that didn't have the command line parameter it wouldn't use the correct profile and all the customizations would be gone so our app wouldn't work.
If you are distributing an internal app with heavy customizations, I would recommend that you make a xulrunner application. That would still have an -app application.ini commandline param, but it would be clearly distinctive from Firefox and cannot be confused with Firefox.
Either way, if the user doesn't use the shortcut that your installer creates, he's off limits and can't expect your app to work. If he gets a normal Firefox in this case, there's no harm done.
I think I will use the Firefox 10.x ESR branch which doesn't have the problem (at least until the next release cycle). It would be nice if this were fixed by then. I don't know if I want to go through the effort of creating an xulrunner application. We've been able to do everything we need thus far by unzipping the install, making modifications and re-bundling with a custom installer and extension. We just need to make sure our app doesn't interact with any version of firefox the user might already have installed. Our extension also allows the user to click on a link to an external web site and it opens the link in the users default browser be it firefox or other but not within our custom app (which doesn't even have a back button)
This may have regressed the functionality added in bug 660687. I am not in a position to test right now, but I'm making a note of it so I remember to test later. I shall be very unhappy if I can't rely on my test builds to stay the hell out of my regular browsing profile.
Having several different versions of Firefox installed side-by-side is a seriously under-served use case. Every single web developer I know has to jump through ever-changing hoops to make this work. It really ought to be as simple as a checkbox in the installer.
Any news about this bug?
We wait but it is very slow...
*** Bug 844508 has been marked as a duplicate of this bug. ***
I would like a little help,
Can you provide me patches for enable application.ini?
Thanks in advance.
Ages later: bug 660687 does not appear to have been regressed, so I no longer have anything to say about this bug.
I don't think we are going to fix this, as stated. We left application.ini in place purely because it's useful from an automation standpoint (being able to grep information about the build from it). The fact that you could edit that data was an implementation detail, not a supported interface.
We'd probably take a patch that let you override these values via environment variable or something like that.
As filed, WONTFIX. File new bugs for the suggestion from comment 23, but only if you plan on providing the patch.
See comment 14 and 12.
"C:\Program Files\Aurora21\firefox.exe" -app "C:\Program Files\Aurora21\application.ini" : does not work.
"C:\Program Files\Aurora21\firefox.exe" -app "C:\Program Files\Aurora21\application.ini" -safe-mode : does not work.
; This file is not used. If you modify it and want the application to use
; your modifications, start with the "-app /path/to/application.ini"
It is not resolved, the solution does not work.
Can you update it?
It is resolved. It will not be fixed. Do not reopen this bug.
*** Bug 874628 has been marked as a duplicate of this bug. ***
I'm finally at the point where I need to upgrade our customized firefox and I thought I would be able to brand it by using command line parameter which worked for an earlier version but on the latest ESR 24.0 version this doesn't work
"C:\[InstallDir]\firefox.exe" -app "C:\[InstallDir]\Application.ini"
It is trying to use my normal firefox profile and completely ignoring the -app parameter.
How can I make it use a custom [App] Vendor and Name so that it doesn't interfere with any installed version of firefox. This is very important for us.
(In reply to Don Kleppinger from comment #30)
> I'm finally at the point where I need to upgrade our customized firefox and
> I thought I would be able to brand it by using command line parameter which
> worked for an earlier version but on the latest ESR 24.0 version this
> doesn't work
> "C:\[InstallDir]\firefox.exe" -app "C:\[InstallDir]\Application.ini"
> It is trying to use my normal firefox profile and completely ignoring the
> -app parameter.
> How can I make it use a custom [App] Vendor and Name so that it doesn't
> interfere with any installed version of firefox. This is very important
> for us.
Unfortunately this is simply not possible anymore. It's quite frustrating.
My only suggestion would be to change your custom build to use a specific profile directory and the parameter "-no-remote".
That will keep it from interfering.
The other alternative is to bypass Firefox completely and use XUL Runner to build something custom.
If I use -no-remote withe -P newprofile It only lets me open one instance of the browser which is not acceptable for us
If I display this url
The information displayed used to come from Application.ini and I could change it which would then cause the profile to not go under Mozilla/firefox but under vendor/name. That would also update the useragent string. Now that doesn't work. I did discover how to modify the values displayed on that url but it doesn't affect the profile location.
I unziped install file and then unzipped core\browser\omni.ja
and then edited \chrome\en-US\locale\branding\brand.properties and zipped everything back up.
I also tried modifying
with a new vendor name but that didn't help either.
I'm still searching the source code for a way to do this.
I just opened bug 933803 because even passing the application.ini via command line isn't working anymore.
FYI I agree with your blog
Good post. http://mike.kaply.com/2013/10/25/the-java-debacle/
This bug is not resolved yet.
Please look: https://bugzilla.mozilla.org/show_bug.cgi?id=933803#c38
Not resolved look my previous comment!
The application.ini is not in browser folder. It is a bug (It is for Firefox, Thunderbird and SeaMonkey)!
You can look:
- Mozilla Firefox folder: http://bioman.blanc.free.fr/bugs/Mozilla/Mozilla%20Firefox%20folder.png
- Mozilla Firefox browser folder: http://bioman.blanc.free.fr/bugs/Mozilla/Mozilla%20Firefox%20browser%20folder.png
- There is not a Mozilla Thunderbird browser folder:
- There is not a SeaMonkey browser folder:
Please resolve this bug which exist since Firefox 11, Thunderbird 11 and SeaMonkey 2.8.
Discussions on :
We are not going to resolve this bug. application.ini will remain in the root folder. You can copy/make your own in the browser folder to solve your use case, or just use the -profile arg.
Please read: https://bugzilla.mozilla.org/show_bug.cgi?id=933803#c8 and other comments.
(In reply to Ben Bucksch (:BenB) from comment #13)
> Don, what's the problem with the commandline parameter?
We use Selenium to test our web app and I can't get selenium to run with a firefox command line parameter. I also read that Selenium also doesn't work for testing XUL apps.
I opened a bug on the selenium forum but have had no response.