Closed Bug 933803 Opened 6 years ago Closed 6 years ago

Firefox doesn't work with -app application.ini

Categories

(Core :: XPCOM, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla28
Tracking Status
firefox25 --- wontfix
firefox26 --- verified
firefox27 --- verified
firefox28 --- verified
firefox-esr24 26+ verified
b2g-v1.2 --- fixed

People

(Reporter: mkaply, Assigned: glandium)

References

Details

Attachments

(1 file)

I duplicated application.ini changing Vendor and and Name.

Then I start Firefox with -app new.ini.

Although I get a profile directory and a profile, Firefox closes and doesn't start.

The error is:

WORKER ERROR DURING SETUP InternalError: uncaught exception: NS_ERROR_FAILURE: Failure
WORKER ERROR DETAIL @resource://gre/modules/osfile.jsm:23
@resource://gre/modules/osfile/osfile_async_worker.js:16
@resource://gre/modules/osfile/osfile_async_worker.js:395

This is broke as far back as Firefox 25.
Blocks: 686466
This is very critical for us.  We have 3000 users using our customized version of firefox and our security compliance audit requires us to be up to date on the browsers security patches.  We created a customized version of firefox using Application.ini so that any existing installation of firefox doesn't step on our profile or visa versa.  
To test I put this in 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=VendorTest
Name=Eagle
Version=6.3
BuildID=20130910201120
SourceRepository=http://hg.mozilla.org/releases/mozilla-esr24
SourceStamp=c5fc2f003e4d
ID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}



[Gecko]
MinVersion=24.0
MaxVersion=24.0

[XRE]
EnableProfileMigrator=0
EnableExtensionManager=1

[Crash Reporter]
Enabled=0
ServerURL=https://crash-reports.mozilla.com/submit?id={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&version=24.0&buildid=20130910201120


-----
Open firefox with -app c:\application.ini

I creates a profile under Users\username\AppData\Local\VendorTest\Eagle.   
but then immediately exists.
David, any idea what the problem is here?  The stack doesn't make a lot of sense.  This is in a worker, so we shouldn't be accessing anything in XPCOM?
Flags: needinfo?(dteller)
I'm trying to upgrade to the 24.0ESR branch and got this failure.  It worked fine on 10.0.11ESR
I can verify this is working in FF17 ESR. I'll see if I can grab some other build and test.
This is most important not for renaming Firefox, but for XULRunner applications. I have several xulrunner apps that I run this way.

I've just tried a self-built 24 nightly on Linux, and starting
.../firefox -app .../myapp/application.ini 
is working fine for me.

But if that was broken, it would indeed be a blocker (in the Bugzilla severity definition sense).
Changing the bug summary to reflect reality. Application.ini override *does* work. It's Firefox that doesn't work with some of the changes you can do to Application.ini. Specifically, It's not even changing vendor and/or name that is broken, it's changing the profile base directory, which, by default, derives from both, but can be changed independently with Profile. That is:

[App]
Vendor=Mozilla
Name=Firefox
Profile=foobar/baz
(...)

This fails, too.
Summary: Application.ini can't be specified via -app → Firefox doesn't work with a different profile base directory set through application.ini
And the cause is bug 755724. And Firefox actually doesn't work without changes to application.ini.

So, the cause of all this is application.ini is really not where it should be, and that's because of our release engineering automation. The only reason application.ini wasn't removed from the firefox tree is because of this. And the end result is that for people who do want to use application.ini to override something, it fails.

So here's how to make this work:
- Copy application.ini to the browser/ subdirectory
- Make your changes
- Start firefox -app path/to/browser/application.ini

Until we can actually remove this file (that is, until releng stops depending on it), the best we can do is modify the comment at the top of the file.
Blocks: metro-build
No longer blocks: 686466
Flags: needinfo?(dteller)
Summary: Firefox doesn't work with a different profile base directory set through application.ini → Firefox doesn't work with -app application.ini
Assignee: nobody → mh+mozilla
Status: NEW → ASSIGNED
glandium +1 for figuring this out. Great work, thanks!
Is this something we can detect and show a better error message?
That did work for me.  That's strange that I have to pass the path to the file but only one specific path works.   Please don't remove this file without giving some way to brand the vendor so that the profile is not put under Mozilla path.  We have a critical web app the depends on custom browser features and we need to make sure that the profile is totally isolated from any firefox installation and can never accidentally be shared as it really messes up the firefox profile if it happens.  It needs to work like a separate product.   I used to be able to brand it by using Application.ini without a command line parameter but you took that feature away from me and now there is the risk that user could start up the renamed.exe without a command line parameter and stomp all over their firefox profile.  Note, using -no-remote -P profile is not an option as it doesn't let you open more than one instance of the browser
(In reply to Mike Kaply (:mkaply) from comment #10)
> Is this something we can detect and show a better error message?

No. Essentially, you're just trying to run a broken xulrunner application.

(In reply to Don Kleppinger from comment #11)
> That did work for me.  That's strange that I have to pass the path to the
> file but only one specific path works.   Please don't remove this file
> without giving some way to brand the vendor so that the profile is not put
> under Mozilla path.  We have a critical web app the depends on custom
> browser features and we need to make sure that the profile is totally
> isolated from any firefox installation and can never accidentally be shared
> as it really messes up the firefox profile if it happens.  It needs to work
> like a separate product.   I used to be able to brand it by using
> Application.ini without a command line parameter but you took that feature
> away from me and now there is the risk that user could start up the
> renamed.exe without a command line parameter and stomp all over their
> firefox profile.  Note, using -no-remote -P profile is not an option as it
> doesn't let you open more than one instance of the browser

You can use the "-profile path" argument, but that gives the full profile path, not a path to the base directory. That being said, if your reason to change the vendor is to change the base profile path, it is a bad reason. You want to *add* a Profile entry to application.ini, as I did in comment 6. Also note that removing the file would not remove the possibility to create one and use it.
It's more than that.  We are modifying and adding features, using a custom installer and a pre-installed custom extension.  When I ran it without the command line parameter it changed a bunch of pre-configured settings (in about:config) in my default firefox profile which was very bad.  We have removed all the chrome(menu's, buttons) so it 's just a window with multiple tabs, no back button or access to any firefox menu's.  And it can't browse to any other website than our webapp.  It does have the ability to open a external link in the users default browser (which will not be this web app)     Most firefox hot keys have been replaced with the web apps hot keys and the user doesn't necessarily even know they are running firefox. Preferences are controlled from the configuration file that loads from autoadmin config file on the server when the browser starts up.
(In reply to Don Kleppinger from comment #13)
> It's more than that.  We are modifying and adding features, using a custom
> installer and a pre-installed custom extension.  When I ran it without the
> command line parameter it changed a bunch of pre-configured settings (in
> about:config) in my default firefox profile which was very bad.  We have
> removed all the chrome(menu's, buttons) so it 's just a window with multiple
> tabs, no back button or access to any firefox menu's.  And it can't browse
> to any other website than our webapp.  It does have the ability to open a
> external link in the users default browser (which will not be this web app) 
> Most firefox hot keys have been replaced with the web apps hot keys and the
> user doesn't necessarily even know they are running firefox. Preferences are
> controlled from the configuration file that loads from autoadmin config file
> on the server when the browser starts up.

This is off topic for this bug, but it looks like what you really want is to use xulrunner, not firefox.
Attachment #826163 - Flags: review?(ted) → review+
I don't know if it's related to my use of the app parameter but I opened another Bug 935281 because athe chrome\userChrome.css from my custom installation is not getting copied from the program installation directory to the profile when firefox starts up and the profile is created.
(In reply to Don Kleppinger from comment #15)
> I don't know if it's related to my use of the app parameter but I opened
> another Bug 935281 because athe chrome\userChrome.css from my custom
> installation is not getting copied from the program installation directory
> to the profile when firefox starts up and the profile is created.

That needs to go in browser/defaults/profile now.

See:

http://mike.kaply.com/2013/04/24/major-changes-coming-in-firefox-21/
https://hg.mozilla.org/mozilla-central/rev/32317b78e332
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
(In reply to Mike Kaply (:mkaply) from comment #16)
> (In reply to Don Kleppinger from comment #15)
> > I don't know if it's related to my use of the app parameter but I opened
> > another Bug 935281 because athe chrome\userChrome.css from my custom
> > installation is not getting copied from the program installation directory
> > to the profile when firefox starts up and the profile is created.
> 
> That needs to go in browser/defaults/profile now.
> 
> See:
> 
> http://mike.kaply.com/2013/04/24/major-changes-coming-in-firefox-21/

That worked!  Thank you for that info and link
Comment on attachment 826163 [details] [diff] [review]
Add a note to application.ini that it needs to be moved under browser/

[Approval Request Comment]
Bug caused by (feature/regressing bug #): See comment 7 for details on the issue.
User impact if declined: People trying to use application.ini to change some Firefox behavior can't figure how to make it work.
Testing completed (on m-c, etc.): Verified on the resulting builds of the m-i push.
Risk to taking this patch (and alternatives if risky): Worst case, application.ini will contain a wrong comment on non-browser builds, and the same comment as it does today on browser builds. Neither would impact functionality. And we already know the patch doesn't lead to that anyways.
String or IDL/UUID changes made by this patch: None

This is especially targetted at esr24, which is even more likely to have people interested in hacking around with application.ini.
Attachment #826163 - Flags: approval-mozilla-esr24?
Attachment #826163 - Flags: approval-mozilla-beta?
Attachment #826163 - Flags: approval-mozilla-aurora?
Attachment #826163 - Flags: approval-mozilla-esr24?
Attachment #826163 - Flags: approval-mozilla-esr24+
Attachment #826163 - Flags: approval-mozilla-beta?
Attachment #826163 - Flags: approval-mozilla-beta+
Attachment #826163 - Flags: approval-mozilla-aurora?
Attachment #826163 - Flags: approval-mozilla-aurora+
Taking this on ESR even though it is outside of the security focus criteria because it breaks mass deployments.
Mike K.  Any idea on Bug 937262 -  It's another issue I'm having with the latest ESR release.  Thanks
I see another problem that may be related.  I'm now using the -app path/to/browser/application.ini startup configuration.  It works fine however if I right click on the icon running on the windows task bar (I have it configured for a different icon)  and select "open new tab" from the context menu, it opens a new tab in my running firefox window, not my custom app.  And if don't have firefox running it opens a window using my firefox profile but not running the firefox executable.  I would be happy if I could remove that context menu item, along with private browsing item which has the same problem.
Keywords: verifyme
There are prefs that control whether or not those things on the icon display:

Setting browser.taskbar.lists.enabled to false removes everything from the jump list.

Setting browser.taskbar.lists.tasks.enabled to false just removes the tasks (leaves the history).
Mike, could you please provide some steps to reproduce or any kind of information that might help us verify this bug fix?
Flags: needinfo?(mh+mozilla)
Those preferences do not disable those icons when using application.ini
Here's how to duplicate

Copy Application.ini to browser directory
Edit Application.ini and change vendor and name properties so it will create a new profile using those values
Start firfox with this shortcut

"C:\Program Files (x86)\Mozilla Firefox\firefox.exe" -app "C:\Program Files (x86)\Mozilla Firefox\browser\APPLICATION.INI"

View Help/Troubleshooting info menu item
Notice that userAgent changed to have the different vendor/name
In about:config set
 browser.taskbar.lists.enabled to false
Open new tab/new window options are still there (they do disappear if not using the Application.ini parameter)
Select open new tab from the context menu.   Window opens using your firefox profile.   
View Help/Troubleshooting info menu item
Notice that userAgent is Mozilla/Firefox.
Don, bugzilla isn't a tech support forum. As you can see from comment 27, there is real work for people that follows from bug reports. The favicon issue is not the problem originally reported here. Please ask about this on a web forum or mailing list, not in bugzilla. Thank you.
This is still a bug related to using -APP parameter but I can open a separate bug if I should.
Don, please do *not* open a new bug. Please find a web forum or mailing list, *not* bugzilla. This is not the right forum. Thanks.
How does that get the bug fixed?  This is just as serious as the original bug that Mike opened on my behalf
(In reply to Andrei Vaida, QA [:AndreiVaida] from comment #27)
> Mike, could you please provide some steps to reproduce or any kind of
> information that might help us verify this bug fix?

The only thing to check is whether the text at the top of application.ini in builds with the fix have a mention about moving the file under browser/.
Flags: needinfo?(mh+mozilla)
(In reply to Mike Hommey [:glandium] from comment #33)
> (In reply to Andrei Vaida, QA [:AndreiVaida] from comment #27)
> > Mike, could you please provide some steps to reproduce or any kind of
> > information that might help us verify this bug fix?
> 
> The only thing to check is whether the text at the top of application.ini in
> builds with the fix have a mention about moving the file under browser/.

Thank you Mike. I was able to confirm the fix for this issue using:
- ESR 24.1.1 (BuildID: 20131112155850): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
- Beta 26.0b8 (BuildID: 20131125215016): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
- Aurora 27.0a2 (BuildID: 20131127004001): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0
- Nightly 28.0a1 (BuildID: 20131127030201): Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:28.0) Gecko/20100101 Firefox/28.0

under Windows 7 x64.
Status: RESOLVED → VERIFIED
Note that this bug was originaly described in #723493.
https://bugzilla.mozilla.org/show_bug.cgi?id=723493

Since Firefox 11+, Thunderbird 11+, SeaMonkey 2.8+.
It is not fixed, Firefix 27.0.1 it does not work, test example:
- "C:\Program Files (x86)\Mozilla Firefox\firefox.exe" -app "C:\Program Files (x86)\Mozilla Firefox\application.ini"
- "C:\Firefox27\firefox.exe" -app "C:\Firefox27\application.ini"
- "C:\Firefox27\firefox.exe" -app "C:\application.ini"
The fix described in this bug was a documentation change not a code change.  Application.ini must go under the browser directory.  This is the only way it will work
example
C:\Program Files (x86)\Mozilla Firefox\firefox.exe" -app "C:\Program Files (x86)\Mozilla Firefox\browser\application.ini"
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
how to change this bug in not resolved???
Mike Kaply (:mkaply), please reopen your ticket ("VERIFIED FIXED" noted but it is false) and which is a duplicate that my tickets :
- 2012-02-02 06:10 PST: https://bugzilla.mozilla.org/show_bug.cgi?id=723493
- 2013-05-21 14:29 PDT: https://bugzilla.mozilla.org/show_bug.cgi?id=874628

Ping to:
Ben Bucksch (:BenB)
Mike Hommey [:glandium]
Andrei Vaida, QA [:AndreiVaida]
Ioana Budnar, QA [:ioana]
Don Kleppinger
Neustradamus:

I don't think you understand what this bug was about.

First off, the application.ini is not used by default at all anymore. Changes to it do nothing unless you invoke Firefox with the -app parameter. There was discussion of removing it, but it was discovered that there are some tools and other things that rely on application.ini being there. So it was left behind.

When the browser subdirectory was moved, it was discovered that application.ini had to be in the browser subdirectory in order to work properly with the -app parameter. But we still needed it in the EXE subdirectory for the above mentioned tools.

So the change was to put this comment at the top of the file:

; This file is not used. If you modify it and want the application to use
; your modifications, move it under the browser/ subdirectory and start with
; the "-app /path/to/browser/application.ini" argument.

If you want to use application.ini, YOU have to move it to the browser folder. It will never be there by default.
It works for Thunderbird and SeaMonkey too?
(In reply to Neustradamus from comment #42)
> It works for Thunderbird and SeaMonkey too?

Thunderbird and SeaMonkey don't support the -app flag, so this isn't an issue for them.
You need to log in before you can comment on or make changes to this bug.