Closed
Bug 631010
Opened 13 years ago
Closed 13 years ago
Plus sign not escaped in %s quick search created using "Add a Keyword for this Search..."
Categories
(Firefox :: Bookmarks & History, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 359809
People
(Reporter: grddev, Unassigned)
Details
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 When creating a quick search by right-clicking the text-field on google.com, the resulting quick search does not correctly escape +. Reproducible: Always Steps to Reproduce: 1. Go to http://www.google.com/ncr 2. Right click text-field and select "Add a Keyword for this Search..." 3. Specify test as keyword 4. Enter test + in location bar Actual Results: URL: http://www.google.com/search?q=+ Searching for a single space Expected Results: URL: http://www.google.com/search?q=%2B Searching for a single plus If I go into "Organize Bookmarks...", and manually create a new bookmark with the same URL and keyword, + is escaped just fine. If I search for an arbitrary term, select "Bookmark This Page", and edit the URL to include %s and add a keyword, + is escape just fine. Through a lot of digging, I have established the following theory. The culprit seems to be the snippet starting on line 2236 of browser.js in the function getShortcutOrURI (http://hg.mozilla.org/mozilla-central/file/7abdd2abd9cb/browser/base/content/browser.js#l2236) If a charset has been set, then the string is converted to the desired charset and then escaped using escape, which performs URL escaping except for some symbols (including '+'). If the charset has not been set, then the second branch applies encodeURIComponent which performs full URL escaping. When a bookmark is added in the two alternative ways above, no corresponding entry is added to the places database, and thus the second code path applies. When selecting "Add a keyword for this Search...", the URL is added to the places database, which correctly records the charset for the google search as "UTF-8", thus resulting in the first code path being executed. There seems to be no obviously simple way to remove the entry from the places database, but a workaround is just to copy the URL into a new bookmark and removing the old one. Looking at the history of the code in getShortcutOrURI, this particular snippet was added in response to bug 258223, but it is not clear to me why one of the code paths use encode and the other encodeURIComponent. In any case, the handling of charset="UTF-8" should probably be the same as when no charset is available, given the comment in getShortcutOrURI.
Updated•13 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•