User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060821 BonEcho/2.0b2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060821 BonEcho/2.0b2 It doesn't detect that a site's search has already been added and goes through the whole "Glow and Add" routine again Reproducible: Always Steps to Reproduce: 1. Visit http://www.theregister.co.uk/ 2. Search icon glows when detecting that it can be added 3. Add the Register to the list as requested 4. At a later stage, revisit the Register and it doesn't detect that it's already added and glows again, requesting that it be added, again Actual Results: Refer to http://forums.mozillazine.org/viewtopic.php?p=2442438#2442438 which describes the same issue with Wikipedia Expected Results: That an added/existing Search would be detected and no "Glow" would occur
It's because the comparison is case-sensitive: the autodiscovery link says "El Reg search" and the plugin itself says "El Reg Search"
Status: UNCONFIRMED → NEW
Ever confirmed: true
The wikipedia issue is bug 349431, which I was going to dupe this to, but perhaps we should make the title comparison case insensitive to fix issues like these.
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → 2.0 Branch
Summary: Open Search doesn't remember an added search → check to determine whether an engine is already installed is case sensitive
A case-insensitive comparison wouldn't hurt, but I don't think it's the right solution. Since the title provided in the <link> hasn't historically been used for much of anything, and the need to have it match isn't obvious or well known, I expect there will be lots of sites whose <link> titles don't match their real titles even disregarding case. One of the solutions under consideration in bug 349431 would be a better fix. (As a point of comparison, look at the initial titles in the JS on https://addons.mozilla.org/search-engines.php . Not the same issue, of course, but it indicates the prevalence of the problem we're facing.)
(In reply to comment #3) > A case-insensitive comparison wouldn't hurt, but I don't think it's the right > solution. Right - I'm just saying that we should probably do it anyways, since it won't hurt, and is trivial to do in the Firefox 2 time frame. A better solution is still needed (in bug 349431), but likely won't make Firefox 2.
To cover a few more cases without much risk, I'm considering normalizing titles slightly: remove spaces and punctuation, ignore case, and remove |search| if it's present. Then |wikipedia| would match |Search Wikipedia|, and |Search CNN by "Title"| would match |cnnbytitle| (as well as |CNN By Title| and others, of course). Thoughts?
If I was a branch driver, I'd take a case-insensitive patch, and wouldn't even consider taking a strip-whitespace-n-stuff patch.
After some consideration, a fair bit of discussion with Gavin on IRC, and only a little hand-wringing, Gavin and I, at least, have concluded that even adding case-insensitivity is problematic. Doing it for every comparison of an engine name is far-reaching and therefore significantly risky, and doing it only when looking at <link> tags is confusingly inconsistent. (If I already have "WikiSearch" in my list, why should I be able to add "wikisearch" from a JS link, but not from a <link> tag?) So my vote, with some reluctance, is to WONTFIX this, and to put the real solution (preloading the engine) into FF3.
I'm nominating this to block FF2, not because I actually think it should, but so that a triage team will take a look and make a final decision. See previous comment.
Agreed, marking WONTFIX, please make sure the preloading bug is nominated for Fx3 once we have a flag for Fx3
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Flags: blocking-firefox2? → blocking-firefox2-
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.