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.
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
Created attachment 56605 [details] [diff] [review] My mistake from 104305. No need to call strtok() for -P case. carson
Conrad: can you review the patch? === cc firstname.lastname@example.org.
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 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.
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. ***
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.
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..:)
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
Last Resolved: 17 years ago → 17 years ago
Resolution: --- → FIXED
Verified code fix
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.