Mozilla must have access to GTK to run -CreateProfile

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
17 years ago
3 years ago

People

(Reporter: colinp, Assigned: ccarlen)

Tracking

Trunk
mozilla1.6alpha
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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

17 years ago
-> 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
(Reporter)

Comment 3

17 years ago
shaver, any movement on this one?
(Assignee)

Comment 4

17 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

17 years ago
No, a profile is not created.

Updated

17 years ago
Keywords: mozilla1.0, oeone

Comment 6

17 years ago
*** Bug 153318 has been marked as a duplicate of this bug. ***

Comment 7

17 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

17 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

17 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

17 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

17 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

16 years ago
Target Milestone: mozilla1.2alpha → mozilla1.4alpha
(Assignee)

Comment 12

16 years ago
Moving out a bit.
Target Milestone: mozilla1.4alpha → mozilla1.6alpha

Comment 13

15 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

14 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.
QA Contact: ktrina → profile-manager-backend

Updated

9 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX

Comment 15

3 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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.