Last Comment Bug 723493 - (application.ini) application.ini Firefox 11+ (Thunderbird 11+ / SeaMonkey 2.8+)
(application.ini)
: application.ini Firefox 11+ (Thunderbird 11+ / SeaMonkey 2.8+)
Status: RESOLVED INVALID
:
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: Trunk
: x86 Windows Vista
: -- blocker with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 844508 874628 (view as bug list)
Depends on:
Blocks: 686466
  Show dependency treegraph
 
Reported: 2012-02-02 06:10 PST by Neustradamus
Modified: 2015-01-13 11:41 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Neustradamus 2012-02-02 06:10:19 PST
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.

[App]
Vendor=Mozilla
Name=Aurora11
Version=11.0a2

[App]
Vendor=Mozilla
Name=Aurora12
Version=12.0a1

[App]
Vendor=Mozilla
Name=Aurora13
Version=13.0a1

It works for Firefox =< 10.

[App]
Vendor=Mozilla
Name=Aurora10
Version=10.0


Actual results:

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




Expected results:

It must use the profil for Aurora11 / Aurora12 / Aurora13 and not for Firefox, it works for all version =< 10.

application.ini for Aurora11
[App]
Vendor=Mozilla
Name=Aurora11
Version=11.0a2

C:\Users\...\AppData\Roaming\Mozilla\Aurora11 (or C:\Documents and Settings\...\Application Data\Mozilla\Aurora11) must work.

application.ini for Aurora12
[App]
Vendor=Mozilla
Name=Aurora12
Version=12.0a1

C:\Users\...\AppData\Roaming\Mozilla\Aurora12 (or C:\Documents and Settings\...\Application Data\Mozilla\Aurora12) must work.

application.ini for Aurora13
[App]
Vendor=Mozilla
Name=Aurora13
Version=13.0a1

C:\Users\...\AppData\Roaming\Mozilla\Aurora13 (or C:\Documents and Settings\...\Application Data\Mozilla\Aurora13) must work.
Comment 1 Mark Banner (:standard8) 2012-02-22 05:48:12 PST
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.
Comment 2 Mike Kaply [:mkaply] (Out June 27-July 5) 2012-02-22 06:25:55 PST
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?
Comment 3 Neustradamus 2012-02-29 06:06:10 PST
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:
Aurora36
Aurora4
Aurora5
Aurora6
Aurora7
Aurora8
Aurora9
Aurora10
Comment 4 Mike Kaply [:mkaply] (Out June 27-July 5) 2012-02-29 06:43:48 PST
Application.ini doesn't work anymore.

You have to use override.ini and specify it via a command line parameter.
Comment 5 Neustradamus 2012-03-09 03:42:02 PST
How I can use override.ini ?
Comment 6 Mike Kaply [:mkaply] (Out June 27-July 5) 2012-03-09 05:24:42 PST
Put the same content as you did in Application.ini in override.ini

Invoke Firefox with

/INI=[PATH to new override.ini]
Comment 7 Don Kleppinger 2012-03-27 11:35:13 PDT
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.
Comment 8 Mike Kaply [:mkaply] (Out June 27-July 5) 2012-03-27 11:45:16 PDT
> 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.
Comment 9 Don Kleppinger 2012-03-27 12:35:06 PDT
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?
Comment 10 Don Kleppinger 2012-03-27 12:45:13 PDT
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"
Comment 11 Don Kleppinger 2012-03-27 12:56:12 PDT
I tried this but it causes an application crash
"C:\Program Files (x86)\[installdir]\firefox.exe" -override override.ini
Comment 12 Don Kleppinger 2012-03-27 13:19:55 PDT
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.
Comment 13 Ben Bucksch (:BenB) 2012-03-27 14:08:46 PDT
Don, what's the problem with the commandline parameter?
Comment 14 Mike Kaply [:mkaply] (Out June 27-July 5) 2012-03-27 14:12:24 PDT
If you're bundling an application (and maybe renaming the executable), you shouldn't have to add a command line parameter.
Comment 15 Don Kleppinger 2012-03-27 14:15:48 PDT
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.
Comment 16 Ben Bucksch (:BenB) 2012-03-27 14:23:13 PDT
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.
Comment 17 Don Kleppinger 2012-03-27 14:47:49 PDT
Thanks,
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)
Comment 18 Zack Weinberg (:zwol) 2012-10-15 09:03:04 PDT
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.
Comment 19 Neustradamus 2013-01-26 12:14:27 PST
Any news about this bug?

We wait but it is very slow...
Comment 20 Robert Longson 2013-02-23 13:19:22 PST
*** Bug 844508 has been marked as a duplicate of this bug. ***
Comment 21 Neustradamus 2013-02-25 14:09:32 PST
I would like a little help,

Can you provide me patches for enable application.ini?

Thanks in advance.
Comment 22 Zack Weinberg (:zwol) 2013-02-25 14:29:04 PST
Ages later: bug 660687 does not appear to have been regressed, so I no longer have anything to say about this bug.
Comment 23 Ted Mielczarek [:ted.mielczarek] 2013-03-01 05:32:31 PST
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.
Comment 24 Benjamin Smedberg [:bsmedberg] 2013-03-01 06:41:24 PST
As filed, WONTFIX. File new bugs for the suggestion from comment 23, but only if you plan on providing the patch.
Comment 25 Ben Bucksch (:BenB) 2013-03-01 07:15:08 PST
See comment 14 and 12.
Comment 26 Neustradamus 2013-04-24 14:24:26 PDT
"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.


application.ini:

; 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"
; argument.
[App]
Vendor=Mozilla
Name=Aurora21
Version=21.0
BuildID=20130423212553
SourceRepository=http://hg.mozilla.org/releases/mozilla-beta
SourceStamp=04aba2e6927f
ID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}

[Gecko]
MinVersion=21.0
MaxVersion=21.0

[XRE]
EnableProfileMigrator=1
EnableExtensionManager=1

[Crash Reporter]
Enabled=1
ServerURL=https://crash-reports.mozilla.com/submit?id={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&version=21.0&buildid=20130423212553
Comment 27 Neustradamus 2013-05-21 13:54:53 PDT
It is not resolved, the solution does not work.

Can you update it?
Comment 28 Benjamin Smedberg [:bsmedberg] 2013-05-21 14:36:36 PDT
It is resolved. It will not be fixed. Do not reopen this bug.
Comment 29 [:Aleksej] 2013-05-28 06:21:18 PDT
*** Bug 874628 has been marked as a duplicate of this bug. ***
Comment 30 Don Kleppinger 2013-10-31 12:06:46 PDT
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.
Comment 31 Mike Kaply [:mkaply] (Out June 27-July 5) 2013-10-31 12:28:24 PDT
(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.
Comment 32 Don Kleppinger 2013-11-01 08:43:47 PDT
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 
chrome://branding/locale/brand.properties
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
\core\webapprt\webapprt.ini
with a new vendor name but that didn't help either.
I'm still searching the source code for a way to do this.
Comment 33 Mike Kaply [:mkaply] (Out June 27-July 5) 2013-11-01 09:23:31 PDT
I just opened bug 933803 because even passing the application.ini via command line isn't working anymore.
Comment 34 Don Kleppinger 2013-11-01 18:00:53 PDT
Thanks Mike
FYI  I agree with your blog 
Good post. http://mike.kaply.com/2013/10/25/the-java-debacle/
Comment 35 Neustradamus 2014-03-06 20:26:14 PST
This bug is not resolved yet.

Please look: https://bugzilla.mozilla.org/show_bug.cgi?id=933803#c38
Comment 36 Neustradamus 2014-03-16 12:47:06 PDT
Not resolved look my previous comment!
Comment 37 Neustradamus 2014-03-17 11:27:24 PDT
"
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

Note:
- There is not a Mozilla Thunderbird browser folder:
http://bioman.blanc.free.fr/bugs/Mozilla/Mozilla%20Thunderbird%20folder.png
- There is not a SeaMonkey browser folder:
http://bioman.blanc.free.fr/bugs/Mozilla/Mozilla%20SeaMonkey%20folder.png
"

Please resolve this bug which exist since Firefox 11, Thunderbird 11 and SeaMonkey 2.8.

Discussions on :
- https://bugzilla.mozilla.org/show_bug.cgi?id=933803
- https://bugzilla.mozilla.org/show_bug.cgi?id=874628
Comment 38 Benjamin Smedberg [:bsmedberg] 2014-03-17 11:34:36 PDT
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.
Comment 39 Neustradamus 2014-03-17 11:40:32 PDT
Please read: https://bugzilla.mozilla.org/show_bug.cgi?id=933803#c8 and other comments.
Comment 40 Don Kleppinger 2015-01-13 11:41:33 PST
(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.
https://code.google.com/p/selenium/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Stars%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&groupby=&sort=&id=6621

Note You need to log in before you can comment on or make changes to this bug.