Closed
Bug 109762
Opened 23 years ago
Closed 15 years ago
Mozilla must have access to GTK to run -CreateProfile
Categories
(Core Graveyard :: Profile: BackEnd, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
mozilla1.6alpha
People
(Reporter: colinp, Assigned: ccarlen)
References
Details
when you want to create a new profile as such: mozilla -CreateProfile oeone You get the following error: Gtk-WARNING **: cannot open display:
Comment 1•23 years ago
|
||
-> Profile mgmt FE
Assignee: asa → ben
Component: Browser-General → Profile Manager FrontEnd
QA Contact: doronr → ktrina
Comment 2•23 years ago
|
||
not FE.
Assignee: ben → ccarlen
Component: Profile Manager FrontEnd → Profile Manager BackEnd
Reporter | ||
Comment 3•23 years ago
|
||
shaver, any movement on this one?
Assignee | ||
Comment 4•23 years ago
|
||
> 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
Reporter | ||
Comment 5•23 years ago
|
||
No, a profile is not created.
Updated•23 years ago
|
Keywords: mozilla1.0,
oeone
Comment 6•22 years ago
|
||
*** Bug 153318 has been marked as a duplicate of this bug. ***
Comment 7•22 years ago
|
||
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.
Comment 8•22 years ago
|
||
And this makes it difficult/impossible to create profiles for several hundred users automatically with a script run from the console.
Assignee | ||
Comment 9•22 years ago
|
||
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
Comment 10•22 years ago
|
||
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?
Assignee | ||
Comment 11•22 years ago
|
||
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.
Assignee | ||
Updated•22 years ago
|
Target Milestone: mozilla1.2alpha → mozilla1.4alpha
Assignee | ||
Comment 12•22 years ago
|
||
Moving out a bit.
Target Milestone: mozilla1.4alpha → mozilla1.6alpha
Comment 13•20 years ago
|
||
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?
Comment 14•20 years ago
|
||
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.
Updated•15 years ago
|
QA Contact: ktrina → profile-manager-backend
Updated•15 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Comment 15•8 years ago
|
||
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.
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•