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)

x86
Linux
defect
Not set
normal

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:
-> Profile mgmt FE
Assignee: asa → ben
Component: Browser-General → Profile Manager FrontEnd
QA Contact: doronr → ktrina
not FE.
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.
Keywords: mozilla1.0, oeone
*** 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.
QA Contact: ktrina → profile-manager-backend
Status: ASSIGNED → RESOLVED
Closed: 15 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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.