Mozilla has problems with "-p profilename"

VERIFIED FIXED in mozilla0.9.6

Status

Core Graveyard
Profile: BackEnd
--
major
VERIFIED FIXED
17 years ago
2 years ago

People

(Reporter: Matti, Assigned: Conrad Carlen (not reading bugmail))

Tracking

({regression})

Trunk
mozilla0.9.6
x86
Windows 2000
regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

17 years ago
win2k build 20011103.. (CVS)

This is a regression from the last 24-48h.
Usually I start mozilla with "mozilla.exe -p matti" because i have a second test
profile.
It seems that mozilla can't find his profile if i use this switch.

Symptoms: the homepage is gone (mozilla use always mozilla.org/start) and all
Mail accounts are also gone

This works if I use the Profilemanager to select the profile.
(Reporter)

Updated

17 years ago
Keywords: mozilla0.9.6, regression

Comment 1

17 years ago
confirming on win98 2001110503

Comment 2

17 years ago
Now that I think about it, it doesn't seem to happen on linux (cvs build from
4-5 hours ago)

Comment 3

17 years ago
And no problem with 2001110103 win98

Comment 4

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

Comment 5

17 years ago
Maybe because of 104305 ?

(Assignee)

Comment 6

17 years ago
Since this recently broke, and bug 104305 changed this code, I think this is Roy's.

Comment 7

17 years ago
Yap. I checked the LXR and my checkin got mixed up. I'll post a fix 
in a minute.

Assignee: ccarlen → yokoyama

Updated

17 years ago
Status: NEW → ASSIGNED

Comment 8

17 years ago
Created attachment 56605 [details] [diff] [review]
My mistake from 104305. No need to call strtok() for -P case. carson

Comment 9

17 years ago
Conrad: can you review the patch?
=== cc ccarlen@netscape.com.

Updated

17 years ago
Target Milestone: --- → mozilla0.9.6

Updated

17 years ago
Whiteboard: need /r=
(Assignee)

Comment 10

17 years ago
Comment on attachment 56605 [details] [diff] [review]
My mistake from 104305. No need to call strtok() for -P case. carson

r=ccarlen
Attachment #56605 - Flags: review+

Comment 11

17 years ago
alec: can you /sr=?
Whiteboard: need /r= → need /sr=

Comment 12

17 years ago
Hummm, after chatting with conrad, I rollbacked my changes to
see if strtok() was really the problem.
I was sure I reproduced this bug; but now I can't.

Grace?

Comment 13

17 years ago
using today's build - Mozilla- 2001110503 and cannot reproduce 
this bug- ie I can run mozilla -p gbush (or one of my other profiles)
and Mozilla launches as expected.

Comment 14

17 years ago
Comment on attachment 56605 [details] [diff] [review]
My mistake from 104305. No need to call strtok() for -P case. carson

sr=alecf
Attachment #56605 - Flags: superreview+

Updated

17 years ago
Summary: Mozilla have problems with "-p profilename" → Mozilla has problems with "-p profilename"

Comment 15

17 years ago
Mistake should be corrected. I'll check in the patch. Let's
see if anybody can reproduce it tomorrow.

Comment 16

17 years ago
Checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 17

17 years ago
This is fixed with my current build.
Thanks for the quick fix !
(Reporter)

Comment 18

17 years ago
argh, this worked only the first time with my clobber build.
It doesn't work if you start mozilla the second time.

-> reopen
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 19

17 years ago
Matti: Recent changes to -P option was to support DBCS profilename.  
The patch for 104305 converts the given lcale profile name to correct
unicode string.

Having said that and while I am waiting to pull the build, 
I have few questions for you.
1) what is your system locale for W2K?
2) does your profile name 'matti' contain German chars?
3) if 2 is true, then are you starting moz with "mozilla.exe -p german_matti"?

Status: REOPENED → ASSIGNED

Comment 20

17 years ago
Gilles: can you still see the problem? 
Whiteboard: need /sr=

Comment 21

17 years ago
With 2001110603, I get the same problem as Matti :
First launch is ok, next ones not.
And my profile name is "sconest" , just plain ascii

Comment 22

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

Comment 23

17 years ago
I am completely puzzled.  My plain ascii profilename works everytime.
I even changed the system locale to German just for the sake of it.
It still works........

Does anybody can reproduce this in the debug build?Conrad: can you please try to
reproduce this?  
(Reporter)

Comment 24

17 years ago
My debug build shows this :

ProfileName : Matti
WARNING: CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///C:/Dokumente%20und%
20Einstellungen/Matti/Anwendungsdaten/Mozilla/Profiles/Matti/lk2eehqr.slt/chrome
/userChrome.css' failed.  Error code: 18, file D:\moz_source\normal\mozilla\cont
ent\html\style\src\nsCSSLoader.cpp, line 1608
WARNING: CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///C:/Dokumente%20und%
20Einstellungen/Matti/Anwendungsdaten/Mozilla/Profiles/Matti/lk2eehqr.slt/chrome
/userContent.css' failed.  Error code: 18, file D:\moz_source\normal\mozilla\con
tent\html\style\src\nsCSSLoader.cpp, line 1608

Comment 25

17 years ago
Matt: do you have the 'userChrome.css' and 'userContent.css' files in your
../lk2eehqr.slt/chrome/ dir?

I checked my develp machine and i have bothfiles.

Comment 26

17 years ago
By the looks of Matti's log, the ProfileName is parsed correctly :)
but failed to find 'userChrome.css' and 'userContent.css'  :(
I am cc'ing people familiar in the areas.
Funny thing is that the browser is ok for the first launch; but
fails for the second launch.  

kin/brendan:  Does this make sense?

Gilles: Can you identify exactly which build starts to show this symptom?
        Is 2001-10-30-trunk, 2001-11-01-trunk or 2001-11-02-trunk ?
        
Whiteboard: need help
(Reporter)

Comment 27

17 years ago
sorry for the wrong alert !
The two files are missing but they contains no code (i copied them from my other 
profile).
I still see the problem with that 2 files :-(

Complete debug console output :
Type Manifest File: D:\moz_source\normal\mozilla\dist\WIN32_D.OBJ\bin\components
\xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
ProfileName : Matti
WEBSHELL+ = 1
Searching for plugins at: D:\moz_source\normal\mozilla\dist\WIN32_D.OBJ\bin\plug
ins
Searching for plugins at: C:\Programme\Netscape\Communicator\Program\Plugins
For application/x-java-vm found plugin D:\moz_source\normal\mozilla\dist\WIN32_D
.OBJ\bin\plugins\NPOJI600.dll
WEBSHELL+ = 2
Note: verifyreflow is disabled
Note: styleverifytree is disabled
Note: frameverifytree is disabled
WEBSHELL+ = 3
###!!! ASSERTION: cannot handle open-ended tag name query: 'Error', file D:\moz_
source\normal\mozilla\content\xul\templates\src\nsContentTagTestNode.cpp, line 8
4
Start reading in bookmarks.html
Finished reading in bookmarks.html  (40000 microseconds)
Document http://www.mozilla.org/start loaded successfully
(Reporter)

Comment 28

17 years ago
more informations:
This is not a broken profile problem. 
I have 2 profiles - both are not working with the -p switch
I created a new (third) profile and this new profile also doesn't work.

I can give you more informations tomorrow (if needed)

Comment 29

17 years ago
Roy : build 2001110103 is ok, 2001110209 is not

Comment 30

17 years ago
fwiw userChrome.css and userContent.css are optional files, touch them to get
the warnings to go away. That issue should be covered elsewhere, it's been this
way for ages.

I've seen this assertion recently:
###!!! ASSERTION: cannot handle open-ended tag name query: 'Error', file D:\moz_
source\normal\mozilla\content\xul\templates\src\nsContentTagTestNode.cpp, line 8
but i didn't try to find out why.

Comment 31

17 years ago
I tried with a clean install of 2001110703 win98 : the problem is still present.

Comment 32

17 years ago
ok, I see the problem on my dev machine. Investigating.....

Comment 33

17 years ago
I backed out my changes and I still see the problem exists.
It appears something else broke it.  

Updated

17 years ago
Attachment #56605 - Attachment is obsolete: true

Comment 34

17 years ago
It appears that Bug 107346 caused this problem. (which checked in 11/01/2001)
http://bugzilla.mozilla.org/attachment.cgi?id=55533&action=view

The patch calls do_GetService(kChromeRegistryCID, &rv);
only if cmdUI or cmdContent is valid.

Just for the testing purpose, I forced to call the
do_GetService(kChromeRegistryCID, &rv); and then the proper Profile being loaded.
 
==> assigning to dougt

Assignee: yokoyama → dougt
Status: ASSIGNED → NEW
(Assignee)

Comment 35

17 years ago
So, you're saying that if
do_GetService(kChromeRegistryCID, &rv);
isn't called when it is in nsAppRunner.cpp, we can't make -P work?

If so, it's my profile mgr bug. It shouldn't depend on that happening.

Comment 36

17 years ago
>do_GetService(kChromeRegistryCID, &rv);
>isn't called when it is in nsAppRunner.cpp, we can't make -P work?
correct.  

(Assignee)

Comment 37

17 years ago
Taking bug.
When looking at this, did you find out why it fails if that call isn't made?
Assignee: dougt → ccarlen

Comment 38

17 years ago
Sorry. Not by just looking at the function InstallGlobalLocale(nsICmdLineService)
in the nsAppRunner.cpp.

I presume the ProfileManager requires to have the ChromeRegistry Service
available at the beginning?  

Comment 39

17 years ago
It looks like nsChromeRegistry calls do_GetService(nsPref) in its constructor.
That may have some impact.

Comment 40

17 years ago
*** Bug 109015 has been marked as a duplicate of this bug. ***
I noticed this is still a problem using 2001-11-07-03 W2K as I had filed dup bug
109015.

Comment 42

17 years ago
*** Bug 109018 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 43

17 years ago
I'll be looking at this shortly. It was perfectly reproducible on the first try
so should be solvable.

testing new bugzilla feature #25
(Assignee)

Comment 44

17 years ago
Found it. Problem is, the prefs service depends on being created before the
profile is set. On getting a "profile-do-change" notification, it reads the user
prefs. Now, after doug's patch, the prefs service is getting created later (a
good thing), not getting this notification, and we have this problem. The easy
way to fix it is for the profile mgr to do a getService() on the prefs before
this point. This works but the right fix, and what I'll do next, is to make the
pref service not depend on when it is created relative to the profile being set.

P.S. what I was hoping was going to happen by typing #25 in my last post didn't
*** Bug 108893 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 46

17 years ago
Created attachment 57111 [details] [diff] [review]
patch to force prefs to exist

After discussing it with bnesse, it seems better to have the profile mgr ensure
that prefs exist when the profile is set. It doesn't need to make an explicit
call to ReadUserPrefs because the prefs service will do that in response to the
notification it's about to receive.
(Assignee)

Comment 47

17 years ago
cc'ing bnesse for review.
Whiteboard: need help

Comment 48

17 years ago
Comment on attachment 57111 [details] [diff] [review]
patch to force prefs to exist

Should do the trick. r=bnesse.
Attachment #57111 - Flags: review+

Comment 49

17 years ago
Comment on attachment 57111 [details] [diff] [review]
patch to force prefs to exist

cool. 
sr=alecf
its disappointing that this doesn't all happen automatically..:)

Updated

17 years ago
Attachment #57111 - Flags: superreview+
(Assignee)

Comment 50

17 years ago
Thanks for the reviews. I've asked for a= to get this into 0.9.6
a=blizzard on behalf of drivers for 0.9.6
Keywords: mozilla0.9.6 → mozilla0.9.6+
(Assignee)

Comment 52

17 years ago
Checked into trunk. Will check into 0.9.6 as soon as I pull one.
(Assignee)

Comment 53

17 years ago
Checked into 0.9.6
Status: NEW → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 54

17 years ago
Verified code fix
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.