Closed Bug 108383 Opened 23 years ago Closed 23 years ago

Mozilla has problems with "-p profilename"

Categories

(Core Graveyard :: Profile: BackEnd, defect)

Product:
Core Graveyard
Component:
Profile: BackEnd
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.6

People

(Reporter: Matti, Assigned: ccarlen)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

patch to force prefs to exist
977 bytes, patch
bnesse
: review+
alecf
: superreview+
Details | Diff | Splinter Review 
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.
Keywords: mozilla0.9.6, regression
confirming on win98 2001110503
Now that I think about it, it doesn't seem to happen on linux (cvs build from
4-5 hours ago)
And no problem with 2001110103 win98
*** Bug 108570 has been marked as a duplicate of this bug. ***
Maybe because of 104305 ?


Since this recently broke, and bug 104305 changed this code, I think this is Roy's.
Yap. I checked the LXR and my checkin got mixed up. I'll post a fix 
in a minute.
Assignee: ccarlen → yokoyama
Status: NEW → ASSIGNED
Conrad: can you review the patch?
=== cc ccarlen@netscape.com.
Target Milestone: --- → mozilla0.9.6
Whiteboard: need /r=
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+
alec: can you /sr=?
Whiteboard: need /r= → need /sr=
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?
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 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+
Summary: Mozilla have problems with "-p profilename" → Mozilla has problems with "-p profilename"
Mistake should be corrected. I'll check in the patch. Let's
see if anybody can reproduce it tomorrow.
Checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
This is fixed with my current build.
Thanks for the quick fix !
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 → ---
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
Gilles: can you still see the problem?
Whiteboard: need /sr=
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
*** Bug 108706 has been marked as a duplicate of this bug. ***
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?  
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
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.

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
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
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)
Roy : build 2001110103 is ok, 2001110209 is not
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.

I tried with a clean install of 2001110703 win98 : the problem is still present.
ok, I see the problem on my dev machine. Investigating.....
I backed out my changes and I still see the problem exists.
It appears something else broke it.
Attachment #56605 - Attachment is obsolete: true
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
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.
>do_GetService(kChromeRegistryCID, &rv);
>isn't called when it is in nsAppRunner.cpp, we can't make -P work?
correct.  


Taking bug.
When looking at this, did you find out why it fails if that call isn't made?
Assignee: dougt → ccarlen
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?  
It looks like nsChromeRegistry calls do_GetService(nsPref) in its constructor.
That may have some impact.
*** 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.
*** Bug 109018 has been marked as a duplicate of this bug. ***
I'll be looking at this shortly. It was perfectly reproducible on the first try
so should be solvable.

testing new bugzilla feature #25
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. ***
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.
cc'ing bnesse for review.
Whiteboard: need help
Comment on attachment 57111 [details] [diff] [review]
patch to force prefs to exist

Should do the trick. r=bnesse.
Attachment #57111 - Flags: review+
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..:)
Attachment #57111 - Flags: superreview+
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+
Checked into trunk. Will check into 0.9.6 as soon as I pull one.
Checked into 0.9.6
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
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.

Attachment

General

Creator:
Created:
Updated:
Size: