when you want to create a new profile as such: mozilla -CreateProfile oeone You get the following error: Gtk-WARNING **: cannot open display:
-> Profile mgmt FE
Assignee: asa → ben
Component: Browser-General → Profile Manager FrontEnd
QA Contact: doronr → ktrina
Assignee: ben → ccarlen
Component: Profile Manager FrontEnd → Profile Manager BackEnd
shaver, any movement on this one?
> You get the following error: > Gtk-WARNING **: cannot open display: And then what? Does it create the profile or not?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
No, a profile is not created.
*** Bug 153318 has been marked as a duplicate of this bug. ***
the problem: nsAppRunner calls appShell->Initialize before InitializeProfileService. appShell->Initialize calls mAppShell->Create, which sets up the (X) display on a unix machine. if it fails, Mozilla will exit. the display needs to exist before InitializeProfileService is called so that it can (if need be) bring up the Profile Manager.
And this makes it difficult/impossible to create profiles for several hundred users automatically with a script run from the console.
Ick. This is difficult because the appshell needs to be initialized before profile mgr because, often, the profile mgr will need to put up a window. The initialization of appshell can't be done as-needed by the profile mgr because the profile mgr should not be dependent on appshell. I think what would fix this would be to pull the profile mgr's command-line processing out into appshell or even apprunner. Then, -CreateProfile could be handled earlier in the startup process, before the appshell was initialized. Other profile mgr args could be handled later. Unless I can think of an easier way, this isn't going to happen too soon.
Target Milestone: mozilla1.0.1 → mozilla1.2alpha
nsProfile::ProcessArgs has comments to the effect that Mozilla should start up even when -CreateProfile is used. nsProfile::StartupWithArgs says a current profile won't exist if -CreateProfile is used, and it's supposed to exit (which is what actually happens) the question is: does the new profile really need to be initialized in whatever routine creates the profile, and (for the purposes of this bug), does whatever hack is implemented need to (in some cases) somehow get Mozilla to continue loading?
That comment is wrong. The behavior of -CreateProfile, as long as I've known, has been to exit after creating the profile. One way around this: nsProfile::ProcessArgs does not need to handle the -CreateProfile switch. If it did not, some other higher-level code (like in AppRunner.cpp) could, on getting that switch, just call nsIProfile::CreateProfile(), and return back to main (with status == 0, which is not the case now). I don't know how popular this idea will be. Putting more into nsAppRunner.cpp never goes over well. But, I think the cmd-line processing should not be handled by components which are used by various embedding apps. This problem is one of the reasons why.
Target Milestone: mozilla1.2alpha → mozilla1.4alpha
Moving out a bit.
Target Milestone: mozilla1.4alpha → mozilla1.6alpha
Hi! Will anything happen regarding this bug? My last comment is now nearly two years ago... Is there somewhere else maybe a project to create Mozilla profiles without the need of Mozilla itself? Maybe by using templates and creating this binary appreg file?
Hi! I found this page: http://www.alain.knaff.lu/howto/MozillaCustomization/find.html The author publishes two perl scripts that can transform the binary appreg / registry.dat into XML and back to binary. This is all we need. Other people may find these scripts useful, too. They allow creation of Mozilla profiles based on templates without invoking mozilla -createProfile.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
I have similar problem: """ $ DISPLAY= firefox -no-remote -CreateProfile test Unable to init server: Broadway display type not supported: Error: cannot open display: """ What I don't see why firefox needs the display when creating a new profile. This makes it impossible to actually use it in a script that might be running without X. Which makes me have to re-write the firefox way of creating new profiles. So unuseful.
You need to log in before you can comment on or make changes to this bug.