108383 - Mozilla has problems with "-p profilename"

Status: VERIFIED FIXED

(Core Graveyard :: Profile: BackEnd, defect)

Description

[Matthias Versen [:Matti]]

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.

Comment 1

[Gilles Durys]

confirming on win98 2001110503

Comment 2

[Gilles Durys]

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

Comment 3

[Gilles Durys]

And no problem with 2001110103 win98

Comment 4

[Gilles Durys]

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

Comment 5

[Roy Yokoyama]

Maybe because of 104305 ?

Comment 6

[Conrad Carlen (not reading bugmail)]

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

Comment 7

[Roy Yokoyama]

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

Comment 8

[Roy Yokoyama]

Attachment: My mistake from 104305. No need to call strtok() for -P case. carson

Comment 9

[Roy Yokoyama]

Conrad: can you review the patch?
=== cc [e-mail].

Comment 10

[Conrad Carlen (not reading bugmail)]

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

r=ccarlen

Comment 11

[Roy Yokoyama]

alec: can you /sr=?

Comment 12

[Roy Yokoyama]

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

[Grace Bush]

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

[Alec Flett]

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

sr=alecf

Comment 15

[Roy Yokoyama]

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

Comment 16

[Roy Yokoyama]

Checked in

Comment 17

[Matthias Versen [:Matti]]

This is fixed with my current build.
Thanks for the quick fix !

Comment 18

[Matthias Versen [:Matti]]

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

-> reopen

Comment 19

[Roy Yokoyama]

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"?

Comment 20

[Roy Yokoyama]

Gilles: can you still see the problem? 

Comment 21

[Gilles Durys]

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

[Gilles Durys]

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

Comment 23

[Roy Yokoyama]

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?  

Comment 24

[Matthias Versen [:Matti]]

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

[Roy Yokoyama]

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

[Roy Yokoyama]

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 ?
        

Comment 27

[Matthias Versen [:Matti]]

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

Comment 28

[Matthias Versen [:Matti]]

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

[Gilles Durys]

Roy : build 2001110103 is ok, 2001110209 is not

Comment 30

[timeless]

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

[Gilles Durys]

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

Comment 32

[Roy Yokoyama]

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

Comment 33

[Roy Yokoyama]

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

Comment 34

[Roy Yokoyama]

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

Comment 35

[Conrad Carlen (not reading bugmail)]

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

[Roy Yokoyama]

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

Comment 37

[Conrad Carlen (not reading bugmail)]

Taking bug.
When looking at this, did you find out why it fails if that call isn't made?

Comment 38

[Roy Yokoyama]

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

[Roy Yokoyama]

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

Comment 40

[Gilles Durys]

*** Bug 109015 has been marked as a duplicate of this bug. ***

Comment 41

[[not reading bugmail]]

I noticed this is still a problem using 2001-11-07-03 W2K as I had filed dup bug
109015.

Comment 42

[Gilles Durys]

*** Bug 109018 has been marked as a duplicate of this bug. ***

Comment 43

[Conrad Carlen (not reading bugmail)]

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

testing new bugzilla feature #25

Comment 44

[Conrad Carlen (not reading bugmail)]

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

Comment 45

[Alex Vincent [:WeirdAl]]

*** Bug 108893 has been marked as a duplicate of this bug. ***

Comment 46

[Conrad Carlen (not reading bugmail)]

Attachment: 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.

Comment 47

[Conrad Carlen (not reading bugmail)]

cc'ing bnesse for review.

Comment 48

[Brian Nesse (gone)]

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

Should do the trick. r=bnesse.

Comment 49

[Alec Flett]

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..:)

Comment 50

[Conrad Carlen (not reading bugmail)]

Thanks for the reviews. I've asked for a= to get this into 0.9.6

Comment 51

[Christopher Blizzard (:blizzard)]

a=blizzard on behalf of drivers for 0.9.6

Comment 52

[Conrad Carlen (not reading bugmail)]

Checked into trunk. Will check into 0.9.6 as soon as I pull one.

Comment 53

[Conrad Carlen (not reading bugmail)]

Checked into 0.9.6

Comment 54

[K'Trina Medina]

Verified code fix