Closed
Bug 57056
Opened 24 years ago
Closed 24 years ago
search.rdf is not being migrated/created, resulting in no search categories
Categories
(Core Graveyard :: Profile: Migration, defect, P1)
Core Graveyard
Profile: Migration
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.8
People
(Reporter: cmaximus, Assigned: ccarlen)
Details
(Whiteboard: [rtm++] fix checked into branch)
Attachments
(2 files)
1.92 KB,
patch
|
Details | Diff | Splinter Review | |
1.14 KB,
patch
|
Details | Diff | Splinter Review |
***Overview Description: When you migrate an existing 4.x profile your new Seamonkey profile does not contain the file search.rdf. I guess there is no such file to migrate from 4.x so it needs to be created. I believe this to be a regression but I think it may have been broken for a couple weeks. ***Steps to Reproduce: 0) Create a 4.x profile. 1) Launch Profile Manager and migrate an existing 4.x profile and launch. 2) In a navigator window select the toplevel Search menu and choose Search|My Sidebar Search Tab|Advanced. 3) Switch the the search sidebar tab and select the within 'All Engines' dropdown. ***Actual Results: The dropdwon is empty save for 'All Engines' and 'Edit Categories'. ***Expected Results: After those two items should be categories like 'Web', 'Music', 'Shareware', and 'Shopping'. ***Build Date & Platform Bug Found: This definitely shows up on all platform Branch builds 2000101608. ***Additional Builds and Platforms Tested On: I am currently blocked and have not been able to test this on trunk builds. ***Additional Information: I have not done an exhausitve search on migrated files or the complete ramifications of this missing file. I just know that these categories are missing and it's because the search.rdf file is missing (normally located in each profile directory).
You're right, if there's no search.rdf file in the original profile (and there won't be since 4.x never had a search.rdf file) it won't be migrated. This is the same problem that occured with mimetypes.rdf. Bhuvan checked in a fix for that bug. I'm reassiging this to him since I believe this closer to a profile management bug than a migration bug. Although IMHO these types of bugs belong to the groups that are supposed to use these files (i.e. whoever depends on mimetypes.rdf and search.rdf). Those groups should be creating "default" versions of these files if they don't find them.
Assignee: dbragg → racham
Reporter | ||
Comment 2•24 years ago
|
||
this is broken on the trunk also(checked Win98) build 2000101608
Keywords: rtm
Comment 3•24 years ago
|
||
Bhuvan, please reassign this to the search component. I think that's rjc. You should review the change.
Robert, Giving this to you so that Search Component can create/copy a new default search.rdf, if it does not exists in the user profile directory. This will be a better solution than changing the stuff in profilemanager code.
Assignee: racham → rjc
Comment 5•24 years ago
|
||
Ah, you know, search.rdf USED to be copied into the user's profile if it didn't exist... (migration or not)
Comment 6•24 years ago
|
||
I suspect this broke with ccarlen's checkin (Rev 1.110 of mozilla/xpfe/ components/search/src/nsInternetSearchService.cpp) when he switched the search code from using nsIFileLocator to NS_GetSpecialDirectory(NS_APP_SEARCH_50_FILE) as nsIFileLocator internally would copy over the default "search.rdf" into the user's profile directory if it didn't exist.
Comment 7•24 years ago
|
||
Racham, can you explain what's going on here? http://lxr.mozilla.org/seamonkey/source/profile/src/nsProfile.cpp#2074
Assignee: rjc → racham
I agree with Robert. I think we had some mechanism like that in FileLocations. I guess Conrad might have overlooked this. Robert, all that's happening there is that we constructing the path for serach.rdf file. So, what probably should also happen there is to check for the existentce of the file and copy one from default location if does not exists.
Assignee | ||
Comment 10•24 years ago
|
||
The thing to do is to make the nsIDirectoryServiceProvider in nsProfile.cpp copy the default file over if it doesn't exist. Working on a patch.
Status: NEW → ASSIGNED
Assignee | ||
Comment 11•24 years ago
|
||
Assignee | ||
Comment 12•24 years ago
|
||
The above patch ensures that, when asked for the search.rdf file, the default file will be copied if the one in the profile dir doesn't exist. For consistency's sake, the same is done for the mimetypes.rdf file. This is better than just copying it over during migration because if the file is deleted, it will be restored.
Assignee | ||
Comment 13•24 years ago
|
||
Assignee | ||
Comment 14•24 years ago
|
||
Disregard the previous patch. It applied the same fix mimetypes.rdf. Since that was already fixed, doesn't need to be addressed here.
Comment 15•24 years ago
|
||
Simpler patch is dandy. r=rjc
Comment 16•24 years ago
|
||
patch id 17476 (second patch) -> r=racham
Comment 17•24 years ago
|
||
sr=waterson. are there any other files we'll drop on the floor?
Assignee | ||
Comment 18•24 years ago
|
||
No, the other files that were created if they didn't exist are handled during migration. The code which copies those 3 files, though, is a hack and needs to be replaced.
Comment 19•24 years ago
|
||
When you have a small, safe patch with r= and sr=, please put [rtm+] in the status whiteboard so the PDT knows to try and give you an approval.
Whiteboard: [rtm+]
Comment 20•24 years ago
|
||
rtm++ (ignore my previous comment, it was probably for another bug :-(
Whiteboard: [rtm+] → [rtm++]
Assignee | ||
Comment 21•24 years ago
|
||
Fix was checked into the branch. Waiting on the trunk because there is some code there which is supposed to be backed out. As soon as nsProfile.cpp gets back into forward motion, I'll check it in there.
Updated•24 years ago
|
Whiteboard: [rtm++] → [rtm++] fix checked into branch
Assignee | ||
Comment 23•24 years ago
|
||
Argh, I forgot this one. Will check it in soon.
Priority: P3 → P1
Target Milestone: --- → mozilla0.8
Assignee | ||
Comment 24•24 years ago
|
||
The patch which was checked into the NS6 branch was checked into the trunk.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•