search.rdf is not being migrated/created, resulting in no search categories

VERIFIED FIXED in mozilla0.8

Status

P1
major
VERIFIED FIXED
18 years ago
3 years ago

People

(Reporter: cmaximus, Assigned: ccarlen)

Tracking

Trunk
mozilla0.8

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rtm++] fix checked into branch)

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
***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).

Comment 1

18 years ago
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

18 years ago
this is broken on the trunk also(checked Win98) build 2000101608
Keywords: rtm

Comment 3

18 years ago
Bhuvan, please reassign this to the search component.  I think that's rjc.  You
should review the change.

Comment 4

18 years ago
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
Ah, you know, search.rdf USED to be copied into the user's profile if it didn't 
exist... (migration or not)
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.
Racham, can you explain what's going on here?

http://lxr.mozilla.org/seamonkey/source/profile/src/nsProfile.cpp#2074
Assignee: rjc → racham

Comment 8

18 years ago
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.

Comment 9

18 years ago
I spoke to Conrad. Passing it to Conrad..
Assignee: racham → ccarlen
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
Created attachment 17474 [details] [diff] [review]
patch to ensure file exists
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.
Disregard the previous patch. It applied the same fix mimetypes.rdf. Since that
was already fixed, doesn't need to be addressed here.
Simpler patch is dandy.  r=rjc

Comment 16

18 years ago
patch id 17476 (second patch) -> r=racham

Comment 17

18 years ago
sr=waterson. are there any other files we'll drop on the floor?
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

18 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

18 years ago
rtm++ (ignore my previous comment, it was probably for another bug :-(
Whiteboard: [rtm+] → [rtm++]
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.
Whiteboard: [rtm++] → [rtm++] fix checked into branch

Comment 22

18 years ago
Verified on the 10/31 branch Win, Mac and Linux builds.
Keywords: vtrunk
Argh, I forgot this one. Will check it in soon.
Priority: P3 → P1
Target Milestone: --- → mozilla0.8

Updated

18 years ago
Keywords: vtrunk
The patch which was checked into the NS6 branch was checked into the trunk. 
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 25

18 years ago
verified on trunk build 2001010404
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.