Closed Bug 469236 Opened 13 years ago Closed 12 years ago

[10.3] Search Engine Plug-ins with & (e.g. Wikipedia) parsed incorrectly as &&

Categories

(Camino Graveyard :: Toolbars & Menus, defect)

1.8 Branch
PowerPC
macOS
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: okfrank, Assigned: murph)

References

()

Details

(Keywords: fixed1.8.1.21)

Attachments

(1 file, 1 obsolete file)

2.39 KB, patch
stuart.morgan+bugzilla
: review+
mikepinkerton
: superreview+
Details | Diff | Splinter Review
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.8.1.18) Gecko/20081112 Camino/1.6.5 (like Firefox/2.0.0.18)
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.8.1.18) Gecko/20081112 Camino/1.6.5 (like Firefox/2.0.0.18)

In the search box search engine plugin for wikipedia.org I did a search for Duke Ellington and nothing came up. The wikipedia site has it's own search box and searching "Duke Ellington" gives results immediately. I suggest alternate parameter list.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
I went to en.wikipedia.org.

Camino found the search plugin, which I added.

I then typed "duke ellington" in the search field. I was taken to

http://en.wikipedia.org/wiki/Duke_ellington

which redirects to the proper Duke Ellington page at the English Wikipedia.

Searching for "duke ellington" on the Wikipedia site gets the same result, so I don't really see what the issue is here.

I'm not sure how this is a Camino bug either way; we don't write (or have any control over) the search engine plugins other than the default, and if there's something wrong with the search parameters, that's a problem for the plugin author (probably the site's webmaster) to fix.
Component: Plug-ins → Toolbars & Menus
QA Contact: plugins → toolbars
We don't ship a Wikipedia search plug-in (our search page does link to Wikipedia for auto-discovery of Wikipedia's own plug-in), so this isn't a bug we can fix.  As Chris says, you should take this up with the Wikipedia iteslf.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
(In reply to comment #2)
> As Chris says, you should take this up with the Wikipedia iteslf.

Although it does sound, based on my experience, like Wikipedia may have fixed whatever problem you're having with their plugin, so you might want to delete it from your list and then re-add it.

cl
Status: RESOLVED → VERIFIED
Thanks for the quick response. In fact I removed it and reinstalled it and I still had no luck. Maybe it's the fact that I'm still using Mac OS 10.3.9

If it's not the parameters maybe it's the url the paramaters query. But it work for you guys. Never mind. I can live with the old fashion method of going to the site.
Can you tell us what URL (with no results) searching for "Duke Ellington" via the search bar took you to?

On Wikipedia, the "Search" button takes you to

http://en.wikipedia.org/wiki/Special:Search?search=Duke+Ellington&fulltext=Search

but the "Go" button takes you to

http://en.wikipedia.org/wiki/Duke_Ellington
Since there still appears to be interest I enter duke ellington and get
http://en.wikipedia.org/w/index.php?title=Special:Search&search=duke%20ellington

Also the youtube plugin search engine is also not working no parameters are being passed.
The link in comment #6 works but the link in comment 7 does not and it's adding "#38;" to the string
Frank, as a temporary workaround while we figure out how this is happening, you can fix the problem by opening

~/Library/Application Support/Camino/WebSearchEngines.plist

in a text editor and changing any occurrences of "&" in that file to "&".

Reopening for further investigation, since it seems like this might be an OS bug that we could potentially work around.
Status: VERIFIED → UNCONFIRMED
Resolution: INVALID → ---
Murph, is this related to bug 429718 in any way?
Confirming, because I can reproduce this on 10.3.9, too.

Sean, do you have any idea if there's a way we can work around this on 10.3?  Chris's work-around is clumsy (since you have to discover the bug in a plug-in and then quit Camino to fix it manually in the .plist); it'll do if we can't fix the bug, but it's not an optimal way to leave 10.3 users.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Search Engine Plug-in for Wikipedia poor search results → [10.3] Search Engine Plug-in for Wikipedia poor search results
Version: unspecified → 1.8 Branch
Summary: [10.3] Search Engine Plug-in for Wikipedia poor search results → [10.3] Search Engine Plug-ins with & (e.g. Wikipedia) parsed incorrectly as &
This would be a good thing for 1.6.7, if it's possible to fix.
Flags: camino1.6.7?
Thanks for the suggestion will try it tonight.

Also if you have 10.3.9 to test on try the same thing with the 
search engine plugin for youtube I'm getting blank parameters
(In reply to comment #13)
> Also if you have 10.3.9 to test on try the same thing with the 
> search engine plugin for youtube I'm getting blank parameters

Any search engine plugin that has ampersands in its query URL is going to trigger this bug.
Thanks. By removing the & from the wikipedia and youtube search in the plist
file they now both work.

Oddly they had & following the & several times together like this "&&"

I simply deleted each case of & and they both were fixed.

Thanks for the help. I wonder if another simple edit like this could solve my
other problem with mounted dmg files never ejecting
Status: NEW → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
That's just a work-around; we need to see if we can eliminate the problem on our end.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → NEW
Summary: [10.3] Search Engine Plug-ins with & (e.g. Wikipedia) parsed incorrectly as & → [10.3] Search Engine Plug-ins with & (e.g. Wikipedia) parsed incorrectly as &&
Assignee: nobody → murph
Attached patch Fix (obsolete) — Splinter Review
Smokey debugged Camino for me on 10.3, and he verified that the parsed string URL attribute returned (for Wikipedia) is:

http://en.wikipedia.org/w/index.php?title=Special:Search&search=%s

I wanted to make sure what character to look for during parsing, as I wasn't sure if the plist saving was doing some additional encoding (such as & for &).

It's not very slick, but the only way I see us working around this is to simply check for that erroneous character and remove it :-/.
Attachment #359461 - Flags: review?(stuart.morgan+bugzilla)
Comment on attachment 359461 [details] [diff] [review]
Fix

Since the bug is 10.3-only, let's wrap the block in a !10.4+ check.
Attachment #359461 - Flags: review?(stuart.morgan+bugzilla) → review-
Attached patch Fix, v2Splinter Review
Doh, I actually meant to do this in the first place.
Attachment #359461 - Attachment is obsolete: true
Attachment #359777 - Flags: review?(stuart.morgan+bugzilla)
Comment on attachment 359777 [details] [diff] [review]
Fix, v2

r=me
Attachment #359777 - Flags: superreview?(mikepinkerton)
Attachment #359777 - Flags: review?(stuart.morgan+bugzilla)
Attachment #359777 - Flags: review+
Comment on attachment 359777 [details] [diff] [review]
Fix, v2

sr=pink
Attachment #359777 - Flags: superreview?(mikepinkerton) → superreview+
Checked in on the MOZILLA_1_8_BRANCH in advance of 1.6.7.
Status: NEW → RESOLVED
Closed: 13 years ago12 years ago
Flags: camino1.6.7? → camino1.6.7+
Keywords: fixed1.8.1.21
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.