|Summary:||www-client/mozilla-firefox with USE="xulrunner" breaks some FF features|
|Product:||Gentoo Linux||Reporter:||Moritz Bechler <mbechler>|
|Component:||New packages||Assignee:||Mozilla Gentoo Team <mozilla>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Moritz Bechler 2008-11-03 01:24:17 UTC
Building firefox with USE="xulrunner" breaks some firefox features (e.g. handling of "general.config.filename") so imho a warning should be added (especially because several other packages block without xulrunner) that building firefox with xulrunner is not the right thing to do/might cause unexpected problems. It took me several hours to figure out why this wasn't working and might cause a lot of annoying problems. with best regards Moritz Bechler
Comment 1 Raúl Porcel (RETIRED) 2008-11-27 11:00:44 UTC
I changed some stuff in xulrunner, does this still happen?
Comment 2 Moritz Bechler 2008-11-30 20:03:28 UTC
This still happens, and to be more precise this seems to happen because some xulrunner code (and not firefox's autoconfig extension) is used for autoconfig which obviously does not work (e.g. does not even try to open the given the configuration file given in general.config.filename although general.config.filename is reported when using NSPR_LOG_MODULES=MCD:5).
Comment 3 Raúl Porcel (RETIRED) 2008-12-02 20:49:30 UTC
Can you explain how to reproduce this, please?
Comment 4 Moritz Bechler 2008-12-02 21:09:17 UTC
https://developer.mozilla.org/en/MCD,_Mission_Control_Desktop_AKA_AutoConfig is a tutorial on this. The basic steps to reproduce are: 1. set "general.config.filename" to e.g. "firefox.cfg" in all.js (also note that firefox built with xulrunner still uses the really old naming scheme for configuration files - not greprefs/all.js but default/pref/all.js) 2. generate some global configuration file firefox.js and obcufate it using moz-byteshift.pl (available here: http://www.alain.knaff.lu/howto/MozillaCustomization/moz-byteshift.pl) 3. start firefox with a new profile (NSPR_LOG_MODULES=MCD:5 firefox -console) -> configuration from firefox.cfg won't be applied, debug output will show 'general.config.filename = "firefox.cfg"' so let's assume that setting the preference was successful. An strace shows that no attempt to access any firefox.cfg is made. I also added some more debugging code to firefox autoconfig extension but nothing happend so I am assuming that the code run is not the one from the extension.
Comment 5 Pacho Ramos 2008-12-03 18:45:56 UTC
Compiling firefox against xulrunner is also used in opensuse, fedora and mandriva, then, this isn't too strange. This could also be an upstream bug, I have found the following reports related with "general.config.filename" behavior problems: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490814 https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9/+bug/139543
Comment 6 Raúl Porcel (RETIRED) 2008-12-07 15:43:52 UTC
(In reply to comment #4) > 1. set "general.config.filename" to e.g. "firefox.cfg" in all.js (also note > that firefox built with xulrunner still uses the really old naming scheme for > configuration files - not greprefs/all.js but default/pref/all.js) That all.js file is located where?
Comment 7 Raúl Porcel (RETIRED) 2008-12-07 15:49:08 UTC
Ok, nvm, i've should read that doc :P
Comment 8 Raúl Porcel (RETIRED) 2008-12-07 18:26:26 UTC
Okay, please check first if you have an autoconfig dir which is a symlink on /usr/lib/mozilla-firefox/defaults . I've tried this: http://ilias.ca/blog/2005/03/locking-mozilla-firefox-settings/ In /usr/lib/mozilla-firefox/defaults/preferences/ i've created a file called all.js: # cat all.js // pref("general.config.filename", "firefox.cfg"); I also created a file called firefox.txt: // lockPref("network.proxy.type", 0); lockPref("browser.startup.homepage", "http://ilias.ca/"); I've run that byteshift script: ./moz-byteshift.pl -s 13 < firefox.txt > firefox.cfg Then i've started firefox and the homepage is ilias.ca and its locked. Something wrong i'm doing?
Comment 9 Moritz Bechler 2008-12-11 15:57:30 UTC
Ok, I'll try again and dig a bit deeper into this.
Comment 10 Nirbheek Chauhan (RETIRED) 2009-05-14 17:53:09 UTC
USE=xulrunner has been removed from the newer 3.5_beta4 in the overlay -- is this still an issue with the overlay builds?
Comment 11 Nirbheek Chauhan (RETIRED) 2009-07-01 06:31:43 UTC
3.5 is in-tree, still a problem?
Comment 12 Moritz Bechler 2010-01-14 15:48:08 UTC
Sorry it took so long to test ... works with 3.5, thank you.