searchForm and iconUpdateURL parameters are not serialised in sherlock -> mozSearch conversion (icon update and searchForm usage fails for sherlock files after a restart)

RESOLVED FIXED in Firefox 2

Status

()

RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: mail, Assigned: Gavin)

Tracking

({fixed1.8.1})

2.0 Branch
Firefox 2
fixed1.8.1
Points:
---
Bug Flags:
blocking-firefox2 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

As discussed...

When installing a sherlock .src file containing a searchForm parameter in Bon Echo, it is expected that the parameter will be copied to the mozSearch .xml file but it isn't.

Reproducible: Always
Morphing this bug a little bit, I found another attribute that isn't saved to disk after installing a Sherlock plugin.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: searchForm parameter not serialised in sherlock -> mozSearch translation → searchForm and iconUpdateURL parameters are not serialised in sherlock -> mozSearch conversion (icon update and searchForm usage fails for sherlock files after a restart)
Target Milestone: --- → Firefox 2
Version: unspecified → 2.0 Branch
Created attachment 236355 [details] [diff] [review]
patch

SearchForm is being read but not written, IconUpdateUrl isn't being written at all, so it's lost after a restart.
Assignee: nobody → gavin.sharp
Status: NEW → ASSIGNED
Attachment #236355 - Flags: review?(mconnor)
The exact effects of this bug are:

1) Icon updates don't work after installing a Sherlock plugin and restarting the browser.
2) Tools->Web Search or pressing enter in a blank search bar will not go to the correct location if a Sherlock engine specifies a searchForm and the browser is restarted after install.

Since the patch is simple, and introduces little to no risk of regression, I think this bug should block Firefox 2.
Flags: blocking-firefox2?
Whiteboard: [patch-r?]
Flags: blocking-firefox2? → blocking-firefox2+

Updated

12 years ago
Attachment #236355 - Flags: review?(mconnor) → review+
Whiteboard: [patch-r?] → [checkin needed]
I checked this in yesterday but forgot to mark the bug.

mozilla/browser/components/search/nsSearchService.js 	1.81
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed] → [needs approval]
Attachment #236355 - Flags: approval1.8.1?
Comment on attachment 236355 [details] [diff] [review]
patch

a=mconnor on behalf of drivers for 1.8 branch checkin
straightforward, well-understood patch to be more compatible with 1.5 and earlier
Attachment #236355 - Flags: approval1.8.1? → approval1.8.1+
Whiteboard: [needs approval] → [checkin needed (1.8 branch)]
mozilla/browser/components/search/nsSearchService.js 	1.1.2.65
Keywords: fixed1.8.1
Whiteboard: [checkin needed (1.8 branch)]
(Reporter)

Comment 7

12 years ago
This may not be the best place to ask...

Should this be working in either Fx2 nightlies or beta 2?

Because I still seem to be getting the old behaviour. I guess this is something to do with branches but if you could post a one liner to explain it to this ignoramus I would be grateful.
Ugh, yes, this bug as summarized is fixed, but I just realized bug 352768 is not. I will fix and try to get that into tonight's builds.
You need to log in before you can comment on or make changes to this bug.