Closed Bug 469236 Opened 13 years ago Closed 12 years ago
.3] Search Engine Plug-ins with & (e .g . Wikipedia) parsed incorrectly as &&
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:220.127.116.11) Gecko/20081112 Camino/1.6.5 (like Firefox/18.104.22.168) Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:22.214.171.124) Gecko/20081112 Camino/1.6.5 (like Firefox/126.96.36.199) 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
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?
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.
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 ago → 13 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 &&
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-
Doh, I actually meant to do this in the first place.
Comment on attachment 359777 [details] [diff] [review] Fix, v2 r=me
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 ago → 12 years ago
Flags: camino1.6.7? → camino1.6.7+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.