User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Keywords could be used as abbreviations for frequently accessed URL roots, but the 1.0PR release now reinterprets any "/" characters within the substituted string with the escaped entity "%2F" Reproducible: Always Steps to Reproduce: 1. Create a keyword - URL: http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/%s, keyword mozapp 2. Type the following location: mozapp update/content/Fupdate.css Actual Results: Received a 404 for the following page http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/update%2Fcontent%2Fupdate.css Expected Results: Loaded the following page http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/update/content/update.css I use this notation as shortcuts through multiple CVS repositories. See also bug 123006 comment 59
IMHO this is not a bug.
This was done intentionally, but the use described here should not be broken IMO. Using a different variable would solve this problem. For example, %s would substitute the escaped value while %S would sub in the string unescaped. Adding that option, even without corresponding UI, would make the keyword feature much more practical. Much of this is discussed in bug 123006 as mentioned.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: keyword %s expansion no longer works when string includes "/" → keyword %s escapes characters (expansion no longer works when string includes "/")
Summary: keyword %s escapes characters (expansion no longer works when string includes "/") → quick search keyword %s now escapes characters (expansion no longer works when string includes "/", "@")
Concur that an alternate variable would be practical. I use 'keyword <email@address>' for a quicksearch of mine. Inteprets @ > %40 resulting in 404.
*** Bug 272359 has been marked as a duplicate of this bug. ***
Also broken, per the dup: foo bar.html#baz, when conversion to foo/bar.html%23baz fails.
Assignee: vladimir → vladimir+bm
Assignee: vladimir+bm → nobody
Fixed (as well as it can be, and a while back) in bug 258223 - alter the steps to reproduce to create the bookmark ending in %S rather than %s, and type mozapp update/content/update.css without the stray F, and it now worksforme.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
What is mozapp? The patch doesn't seem to be in Deer Park Alpha 2?
Should this work in Firefox 1.0.7 ? I created a shortcut for xls: (with the colon) similar to file:///c:/mysite/dmcritchie/excel/%s works okay for nomal stuff but not for a goal of something like xls: code/test.htm#part2 Changed the %s to %S and retested instead getting an Alert message of xls is not a registered protocol even for a simple xls: . (should get the directory or default index.htm file) Don't know if I should be able to do this in 1.0.7, but I do not understand the second part of your comment. type mozapp update/content/update.css without the stray F, and it now works-for-me. (In reply to comment #8) > What is mozapp? The patch doesn't seem to be in Deer Park Alpha 2?
"mozapp" is the example quicksearch in comment 0, and thus the bug that is supposed to be fixed here. 1.0.7 has only gotten security patches since 1.0, and thus won't have anything fixed, DPa2 is how old, July some time? If you look at bug 258223, where this was fixed, you'll see it was checked in late 20050808/early 20050809.
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → bookmarks
You need to log in before you can comment on or make changes to this bug.