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

Status: RESOLVED FIXED

(Camino Graveyard :: Toolbars & Menus, defect)

Description

[okfrank]

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.

Comment 1

[Chris Lawson (gone)]

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.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 3

[Chris Lawson (gone)]

(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

Comment 4

[okfrank]

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.

Comment 5

[Chris Lawson (gone)]

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

Comment 6

[Chris Lawson (gone)]

The OpenSearch plugin for Wikipedia uses the URL

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

Frank, if you go to

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

what happens?

Comment 7

[okfrank]

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.

Comment 8

[okfrank]

The link in comment #6 works but the link in comment 7 does not and it's adding "#38;" to the string

Comment 9

[Chris Lawson (gone)]

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.

Comment 10

[Chris Lawson (gone)]

Murph, is this related to bug 429718 in any way?

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This would be a good thing for 1.6.7, if it's possible to fix.

Comment 13

[okfrank]

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

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(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.

Comment 15

[okfrank]

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

Comment 16

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

That's just a work-around; we need to see if we can eliminate the problem on our end.

Comment 17

[Sean Murphy]

Attachment: Fix

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 :-/.

Comment 18

[Stuart Morgan]

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.

Comment 19

[Sean Murphy]

Attachment: Fix, v2

Doh, I actually meant to do this in the first place.

Comment 20

[Stuart Morgan]

Comment on attachment 359777 [details] [diff] [review]
Fix, v2

r=me

Comment 21

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 359777 [details] [diff] [review]
Fix, v2

sr=pink

Comment 22

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Checked in on the MOZILLA_1_8_BRANCH in advance of 1.6.7.