Bug 723493 (application.ini)

application.ini Firefox 11+ (Thunderbird 11+ / SeaMonkey 2.8+)

RESOLVED INVALID

Status

()

Firefox
General
--
blocker
RESOLVED INVALID
6 years ago
3 years ago

People

(Reporter: Neustradamus, Unassigned)

Tracking

Trunk
x86
Windows Vista
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
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.
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.
Blocks: 686466

Comment 2

5 years ago
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?
(Reporter)

Comment 3

5 years ago
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

5 years ago
Application.ini doesn't work anymore.

You have to use override.ini and specify it via a command line parameter.
(Reporter)

Comment 5

5 years ago
How I can use override.ini ?

Comment 6

5 years ago
Put the same content as you did in Application.ini in override.ini

Invoke Firefox with

/INI=[PATH to new override.ini]

Comment 7

5 years ago
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

5 years ago
> 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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 9

5 years ago
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

5 years ago
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

5 years ago
I tried this but it causes an application crash
"C:\Program Files (x86)\[installdir]\firefox.exe" -override override.ini

Comment 12

5 years ago
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

5 years ago
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.

Comment 15

5 years ago
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

5 years ago
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

5 years ago
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)

Updated

5 years ago
Component: Untriaged → General
QA Contact: untriaged → general
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.
Blocks: 660687
(Reporter)

Comment 19

5 years ago
Any news about this bug?

We wait but it is very slow...
Alias: Gecko
Summary: application.ini Firefox 11+ → application.ini Firefox 11+ (Thunderbird 11+ / SeaMonkey 2.8+)
(Reporter)

Updated

5 years ago
Severity: normal → blocker

Updated

4 years ago
Duplicate of this bug: 844508
(Reporter)

Comment 21

4 years ago
I would like a little help,

Can you provide me patches for enable application.ini?

Thanks in advance.

Updated

4 years ago
Alias: Gecko → application.ini
Ages later: bug 660687 does not appear to have been regressed, so I no longer have anything to say about this bug.

Updated

4 years ago
No longer blocks: 660687
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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX

Comment 25

4 years ago
See comment 14 and 12.
(Reporter)

Comment 26

4 years ago
"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
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 27

4 years ago
It is not resolved, the solution does not work.

Can you update it?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
It is resolved. It will not be fixed. Do not reopen this bug.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → WONTFIX

Updated

4 years ago
Duplicate of this bug: 874628

Comment 30

4 years ago
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.

Comment 32

4 years ago
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.
I just opened bug 933803 because even passing the application.ini via command line isn't working anymore.

Comment 34

4 years ago
Thanks Mike
FYI  I agree with your blog 
Good post. http://mike.kaply.com/2013/10/25/the-java-debacle/
(Reporter)

Comment 35

3 years ago
This bug is not resolved yet.

Please look: https://bugzilla.mozilla.org/show_bug.cgi?id=933803#c38
(Reporter)

Comment 36

3 years ago
Not resolved look my previous comment!
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(Reporter)

Comment 37

3 years ago
"
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
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.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago3 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 39

3 years ago
Please read: https://bugzilla.mozilla.org/show_bug.cgi?id=933803#c8 and other comments.
Resolution: WONTFIX → INVALID

Comment 40

3 years ago
(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
You need to log in before you can comment on or make changes to this bug.