Bugzilla

Comment 2

•

12 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

•

12 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

•

12 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

•

12 years ago

How I can use override.ini ?

Comment 6

•

12 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

•

12 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

•

12 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

•

12 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

•

12 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

•

12 years ago

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

Comment 12

•

12 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

•

12 years ago

Don, what's the problem with the commandline parameter?

Comment 14

•

12 years ago

If you're bundling an application (and maybe renaming the executable), you shouldn't have to add a command line parameter.

Comment 15

•

12 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

•

12 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

•

12 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)

Nickolay_Ponomarev

Updated

•

12 years ago

Component: Untriaged → General

QA Contact: untriaged → general

Zack Weinberg (:zwol)

Comment 18

•

12 years ago

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

•

11 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

•

11 years ago

Severity: normal → blocker

Reporter

Comment 21

•

11 years ago

I would like a little help,

Can you provide me patches for enable application.ini?

Thanks in advance.

Updated

•

11 years ago

Alias: Gecko → application.ini

Zack Weinberg (:zwol)

Comment 22

•

11 years ago

Ages later: bug 660687 does not appear to have been regressed, so I no longer have anything to say about this bug.

(not currently active) Ted Mielczarek

Updated

•

11 years ago

No longer blocks: 660687

Comment 23

•

11 years ago

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

•

11 years ago

As filed, WONTFIX. File new bugs for the suggestion from comment 23, but only if you plan on providing the patch.

Status: NEW → RESOLVED

Closed: 11 years ago

Resolution: --- → WONTFIX

Comment 25

•

11 years ago

See comment 14 and 12.

Reporter

Comment 26

•

11 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 → ---

Updated

•

11 years ago

Status: REOPENED → RESOLVED

Closed: 11 years ago → 11 years ago

Resolution: --- → WONTFIX

Reporter

Comment 27

•

11 years ago

It is not resolved, the solution does not work.

Can you update it?

Status: RESOLVED → REOPENED

Resolution: WONTFIX → ---

Comment 28

•

11 years ago

It is resolved. It will not be fixed. Do not reopen this bug.

Status: REOPENED → RESOLVED

Closed: 11 years ago → 11 years ago

Resolution: --- → WONTFIX

Comment 30

•

11 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.

Comment 31

•

11 years ago

(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

•

11 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.

Comment 33

•

11 years ago

I just opened bug 933803 because even passing the application.ini via command line isn't working anymore.

Comment 34

•

11 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

•

10 years ago

This bug is not resolved yet.

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

Reporter

Comment 36

•

10 years ago

Not resolved look my previous comment!

Status: RESOLVED → REOPENED

Resolution: WONTFIX → ---

Reporter

Comment 37

•

10 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

Comment 38

•

10 years ago

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

Closed: 11 years ago → 10 years ago

Resolution: --- → WONTFIX

Reporter

Comment 39

•

10 years ago

Please read: https://bugzilla.mozilla.org/show_bug.cgi?id=933803#c8 and other comments.

Resolution: WONTFIX → INVALID