Closed Bug 44397 Opened 25 years ago Closed 25 years ago

Create Profile creates no bookmarks

Categories

(SeaMonkey :: Bookmarks & History, defect, P3)

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jlarsen, Assigned: mscott)

References

Details

(Whiteboard: [nsbeta2+] ETA 7/18)

Attachments

(1 file)

a short term quick fix to layout\html\src\nsHTMLDocument.cpp
1.05 KB, patch
Details | Diff | Splinter Review
Create Profile button in profile manager for the last couple of days has not been creating the default bookmarks, or anything else really in the profile. Seems to create a blank profile.
reassigning to racham. Grace or Bhuvan are you able to duplicate this? If this is reproduceable it should probably get nominated for beta2.
Assignee: putterman → racham
Looks like app is not finding default bookmarks where it is supposed to find. Proobably some of Tao's recent changes caused this. All profile manager does on new profile creation is to identify the location where the default profile files are and just copy them over... I will try to reproduce this and see what happens...
I see this problem with the build downloaded from sweetlou (commercial build). My debug build is almost ready....Nothing on the profile manager front has changed to trigger this behavior. I suspect failure to get language_pack details or failure with filespec operations as reasons, on the first cut. Will post more details soon. Adding nsbeta2 keyword.
Status: NEW → ASSIGNED
Keywords: nsbeta2
OK....I see some interesting things here.... The (valid default 7kb) bookmarks file exists in the newly created user profile directory. But it just not getting loaded when launched with newly created profile. If I quit the browser and launch the browser again, I see all bookmarks. Looks like bookmark service is failing to get profile directory in the new profile case..OR...it could be failure in rdf to read the bookmarks file on the first run.... Reassining to Robert.
Assignee: racham → rjc
Status: ASSIGNED → NEW
Component: Profile Manager BackEnd → Bookmarks
Bhuvan, if you set a breakpoint at nsBookmarksService::Init() [in mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp around line # 1920] and then run Mozilla with the option to create a profile, you'll see that the breakpoint triggers when you click on the "Create Profile" button in the Profile Manager dialog. Looking up the stack, in LoadDefaultProfileDir() [in nsProfile.cpp around lin # 316] the appshell's Run() method is being called which (since its the app's main event loop) ends up doing a lot of work too early, including reading in bookmarks (before the default bookmarks.html file has been copied). Basically, you need to ensure that hiddenWindow.xul is not loaded in (which causes bookmarks.html to be read in) until completely AFTER the new profile has been created and fully populated with all relevant files. I'd suggest first looking at recent changes to this section of code and seeing what's changed.
Assignee: rjc → racham
Status: NEW → ASSIGNED
Putting on [nsbeta2-] radar. Not critical to beta2. Adding "nsbeta3" keyword for consideration of a fix for that milestone.
Keywords: nsbeta3
Whiteboard: [nsbeta2-]
*** Bug 44339 has been marked as a duplicate of this bug. ***
changing platform to ALL/ALL
OS: Windows 95 → All
Hardware: PC → All
I spoke to Robert about this. It looks like someone is triggering hiddenWindow to load when the Create New Profile Link is clicked. It could be profile manager frontend too...I haven't got a chance to look at the bug yet. Adding Ben to cc list in case he is doing something that causes hidden window to load...
Nope, not me. And all the code that was in the profile manager that used to depend on the presence of hidden window (javascript:alert(), etc) have all been removed and replaced with direct calls into nsICommonDialogs
Whiteboard: [nsbeta2-]
New information. If there are no bookmarks whatsoever, then the user can't add any bookmarks at all - it breaks the bookmarks functionality entirely. See similar bug 44034. renominating nsbeta2 since this bug completely breaks bookmarks. I recommended a minus earlier in PDT, but we did not realize that problem then. More serious then we thought. Only saving grace is that this only happens when a user creates a new profile, but working bookmarks is such a key piece of functionality for a browser (analogous to saving emails in a folder in Mail - we couldn't ship without that) that no bookmarks with a new profile is almost like saying that "create a new profile" doesn't work.
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
*** Bug 45274 has been marked as a duplicate of this bug. ***
I tried putting breakpoints in couple places to see if hiddenwindow is getting loaded earlier. I haven't hit any of those breakpoints. While trying to undserstand the process that is initializing the bookmarks service before a profile is avaialble, I ran into the following stack trace when I put a breakpoint at Init() of nsBookmarksService.cpp. I found that explicit request is made to get DataSource for "rdf:bookmarks" on the following line of code. nsHTMLDocument::StartDocumentLoad(nsHTMLDocument * const 0x027aa660, const char * 0x0035934c, nsIChannel * 0x027ad8f0, nsILoadGroup * 0x027ac180, nsISupports * 0x027ab6b0, nsIStreamListener * * 0x0012d84c, int 1) line 725 + 52 bytes This piece of code is added by Doug Turner (added him to the cc list). This change is made on June 26th and looks like this problem has popped out around the same time. Doug, do you think if this change causing this regression...? Stack Trace : nsBookmarksService::Init() line 1922 nsBookmarksServiceConstructor(nsISupports * 0x00000000, const nsID & {...}, void * * 0x0012c8d4) line 5002 + 146 bytes nsGenericFactory::CreateInstance(nsGenericFactory * const 0x027a99c0, nsISupports * 0x00000000, const nsID & {...}, void * * 0x0012c8d4) line 48 nsComponentManagerImpl::CreateInstance(nsComponentManagerImpl * const 0x00c54620, const nsID & {...}, nsISupports * 0x00000000, const nsID & {...}, void * * 0x0012c8d4) line 1237 + 24 bytes nsComponentManager::CreateInstance(const nsID & {...}, nsISupports * 0x00000000, const nsID & {...}, void * * 0x0012c8d4) line 82 nsServiceManagerImpl::GetService(nsServiceManagerImpl * const 0x00c54990, const nsID & {...}, const nsID & {...}, nsISupports * * 0x0012ca68, nsIShutdownListener * 0x00000000) line 346 + 19 bytes nsServiceManagerImpl::GetService(nsServiceManagerImpl * const 0x00c54990, const char * 0x0012cb08, const nsID & {...}, nsISupports * * 0x0012ca68, nsIShutdownListener * 0x00000000) line 494 nsServiceManager::GetService(const char * 0x0012cb08, const nsID & {...}, nsISupports * * 0x0012ca68, nsIShutdownListener * 0x00000000) line 607 RDFServiceImpl::GetDataSource(RDFServiceImpl * const 0x0106c260, const char * 0x01dedba0, nsIRDFDataSource * * 0x0012cda8) line 1101 + 50 bytes nsHTMLDocument::StartDocumentLoad(nsHTMLDocument * const 0x027aa660, const char * 0x0035934c, nsIChannel * 0x027ad8f0, nsILoadGroup * 0x027ac180, nsISupports * 0x027ab6b0, nsIStreamListener * * 0x0012d84c, int 1) line 725 + 52 bytes nsLayoutDLF::CreateDocument(const char * 0x0035934c, nsIChannel * 0x027ad8f0, nsILoadGroup * 0x027ac180, nsISupports * 0x027ab6b0, const nsID & {...}, nsIStreamListener * * 0x0012d84c, nsIContentViewer * * 0x0012d6fc) line 390 + 45 bytes nsLayoutDLF::CreateInstance(nsLayoutDLF * const 0x027a8060, const char * 0x0035934c, nsIChannel * 0x027ad8f0, nsILoadGroup * 0x027ac180, const char * 0x0012d7f8, nsISupports * 0x027ab6b0, nsISupports * 0x00000000, nsIStreamListener * * 0x0012d84c, nsIContentViewer * * 0x0012d6fc) line 271 + 37 bytes nsDocShell::NewContentViewerObj(nsDocShell * const 0x027ab690, const char * 0x0012d7f8, nsIChannel * 0x027ad8f0, nsILoadGroup * 0x027ac180, nsIStreamListener * * 0x0012d84c, nsIContentViewer * * 0x0012d6fc) line 2389 + 132 bytes nsDocShell::CreateContentViewer(nsDocShell * const 0x027ab690, const char * 0x0012d7f8, nsIChannel * 0x027ad8f0, nsIStreamListener * * 0x0012d84c) line 2329 + 60 bytes nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x027ab110, const char * 0x0012d7f8, int 0, const char * 0x1009fc08 gCommonEmptyBuffer, nsIChannel * 0x027ad8f0, nsIStreamListener * * 0x0012d84c, int * 0x0012d7dc) line 100 + 33 bytes nsDocumentOpenInfo::DispatchContent(nsIChannel * 0x027ad8f0, nsISupports * 0x00000000) line 359 + 109 bytes nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x027ad880, nsIChannel * 0x027ad8f0, nsISupports * 0x00000000) line 233 + 16 bytes nsStreamIOChannel::OnStartRequest(nsStreamIOChannel * const 0x027ad8f4, nsIChannel * 0x027ad770, nsISupports * 0x00000000) line 597 nsOnStartRequestEvent::HandleEvent(nsOnStartRequestEvent * const 0x027ade80) line 210 + 26 bytes nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x027ade30) line 97 + 12 bytes PL_HandleEvent(PLEvent * 0x027ade30) line 587 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x026ca5f0) line 528 + 9 bytes _md_EventReceiverProc(HWND__ * 0x06e60608, unsigned int 49494, unsigned int 0, long 40674800) line 1043 + 9 bytes USER32! 77e71820() 026ca5f0()
Whiteboard: [nsbeta2+] → [nsbeta2+] ETA 7/18
If I'm reading this stack trace correctly, layout is actually attempting to load bookmarks! That seems pretty whacked. nsHTMLDocument::StartDocumentLoad is invoking the RDF service and asking it to initialize bookmarks. Is anyone on the cc list down to zero nsbeta2+ bugs that might be able to help debug this? I think we could use some help.
Oh I just read all of bhuvan's comments. Looks like dougt made the change for nsHTMLDocument::StartDocumentLoad to create the bookmarks service. Doug, this breakes bookmarks when creating a new profile because in displaying the profile window layout is attempting to access bookmarks before a profile is selected. Should we re-assign this to you?
My changes was to /remove/ the the bookmark dependancy. My change was to not set the rv which was being used to test for failure, but use the rv_detect. Here is the diff: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&fi le=nsHTMLDocument.cpp&root=/cvsroot&subdir=mozilla/layout/html/document/src&comm and=DIFF_FRAMESET&rev1=3.248&rev2=3.249
after I create a new profile, and examine the content of the profile directory, I find that the default bookmark file is only 1k and only contains the "Imported IE Favorites" li.
after reverting my changes, this problem persists.
Hmm so doug's findings seem to re-enforce the theory that a hidden widden is getting created somewhere. That would explain why the html document is then accessing bookmarks in the on start document.
doug has mentioned that the bookmark is only 1k in size. But I didn't find that to be true. For newly created profiles, I saw a bookmark file of size 7kb on commercial build and 13kb on mozilla build. It is not the empty bookmark file...I guess it is the hiddenwindow....causing the damage.
If it is the hidden window then it might be interesting to see what url is getting loaded in it. We should be able to find that out with a break point in nsHTMLDocument::StartDocumentLoad
Okay I've figured out what's going on. But I have no idea how this could have worked before after seeing the problem. The problem really is as simple as nsHTMLDocument::StartDocumentLoad attempting to access bookmarks. This happens when you create a new profile because we load createProfileWizard.xul. This xul file contains an html:iframe which is initialized to about:blank. Still with me? The actual loading of about:blank in the iframe of course triggers the call in nsHTMLDocument::StartDocumentLoad. And this method then gets the bookmarks service and gets the charset from the last url we visited (for some reason unknown to me). There's the problem in a nut shell. Looking at the code, it looks like the create profile wizard has always used an iframe and initialized it to about:blank. So I'm not sure how this could have worked before. I'm having serious issues (besides the fact that it causes this problem) with nsHTMLDocument::StartDocumentLoad trying to use the bookmarks service. Does anyone else think this is really evil? Maybe a layout person should answer this. I'm not sure about the fix yet.
Can't bookmarks do whatever it wants to do as a document load observer or something (e.g., the same way related links works)?
Chris, you lost me on your comments I'm afraid. What do you mean? I'm trying a quick band aid fix for right now which is to not invoke bookmarks if the html document is just loading about:blank.
This smells familiar... I think nhotta or one of the other I18N guys might have added this within the last month or so. (Might want to do a cvs blame on the offending lines and see who checked 'em in.) If I remember correctly, there was some I18N desire to do something with document charsets. (I love being vague.) Anyway, also cc'ing nhotta for any info he might have.
It was jbetak, not nhotta... cc'ing him.
A quick fix would be to check the URL in question against "about:blank" (*before* trying to get the bookmarks service) and, if it is, then just skipping all the bookmark's charset stuff.
> mscott: I'm trying a quick band aid fix for right now which is to not invoke bookmarks if the html document is just loading about:blank. Right! :^)
dammit rjc keeps stomping on my comments so I keep losing my postings =). I'm totally not buying this solution of using bookmarks to get the last document charset in layout. This is seems like a really evil dependency of layout on bookmarks to me. Plus it causes this bug! Am I off base here in thinking this way? I'll take this from bhuvan since it clearly isn't a profile bug and he has other nsbeta2 stuff to worry about.
Assignee: racham → mscott
Status: ASSIGNED → NEW
> dammit rjc keeps stomping on my comments so I keep losing my postings HEHE Welcome to hell, mscott.
=) Okay, attaching the get rich quick fix to this bug. Although I'm loath to check this in until I'm convinced layout really wants this bookmarks stuff here =).
No, I don't think we want bookmarks there. I wish that there was another way to do this. mscott: go ahead and check in that fix. We should file a bug (cc jud and embedding folks) to untangle this junk.
that's a bug? that's a really great FEATURE :-) Finally you create a NEW profile and you get a NEW and EMPTY profile! I love this bug. Please don't "fix" it.
I checked in this dirty little hack until we can get rid of the bookmarks code in layout. This problem is already tracked in Bug #43082 as dougt mentioned.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I know that Niko's comment doesn't really deserve and answer, but I'm going to give one. Niko, what happends is that when you create a profile, on FIRST run there are no bookmarks, and whatmore the bookmarks themselves don't even work (ie you can't add more) On later runs of the program the bookmarks are there and work fine. It sounds like what your asking if for it to have a option where you can by choice create a truly blank profile. If that is what you really want add a new bug report with [RFE] in the beginning of the subject line (stands for Request for Enhancement) and ask for that to be an option feature, or code it yourself -grin-. Though honestly I'll tell you, that even if the mozilla people code it in, it will probably be removed from Netscape 6.0 as AOL kinda likes the ads :) -grin- oh well.
no longer seen on any builds 2000-07-20-08-M17
Status: RESOLVED → VERIFIED
no longer seen on any builds 2000-07-20-08-M17
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: