As of very recently, my custom keywords are all broken. b 1234 trys to load www.b 1234.com, which is fairly stupid. Linux 2002010808.
wfm linux 2002010821
jmd please give more information. Specifically, what are your custom keywords that are broken and the URL they point to? Also, Dumb question, but I have to ask: are you sure they still exist in your bookmarks and didn't get deleted somehow? WFM linux 2002010808 and 2002011010.
Two of many are: v = http://validator.w3.org/check?uri=%s;outline=1 b = http://bugzilla.mozilla.org/show_bug.cgi?id=%s Still not firing in todays build, 2002011008 Linux. I've removed and reset the keyword, no help. I heard from someone else Asa was also seeing this. Asa?
I just added those keywords, and they work fine for me. JMD, note that you need to restart the browser for custom keywords to take effect, that's bug 91945. Try on today's build?
Oh you already tried today's build, nm...
broken in win98 2002010803, 2002011003. os->all
Asa said it's only broken for urls which live in your personal toolbar folder.
My custom keywords are not in (or under) the personal toolbar. They are in a top level folder 'kw'.
I'm seeing this, linux, checkout finish: Mon Jan 7 23:15:17 GMT 2002 The problem is weird, I actually got it to work again after "editing" the keyword. One such keyword is "mozbug" with the obvious %s pattern going to bugzilla. Also, internet keyword search to google is broken for me right now too, but that is also intermittent, and sometimes works. I haven't been able to discern a pattern. Moz corrupted my preferences at one point, defaulting back to netscape instead of google, and disabling internet keywords. No other problems were seen. I'm open to /any/ ideas...
new kw bookmark at bookmarks root -> works. new kw bookmark in a folder -> works. old kw bookmark in a folder ("keyword") -> doesn't work. old kw bookmark in a folder, changed kw or name -> works. old kw bookmark in a folder, changed location -> might work. old kw bookmark in a folder, changed description -> doesn't work. Nothing seems to have changed in bookmarks.html after changing the bookmarks and changing back. I didn't actually bother to back up any other files, silly me, so I wouldn't know where it gets fixed.
Nothing changes ANYWHERE in my profile, except the obvious: % diff -r fd6xpkra.slt 1 diff -r fd6xpkra.slt/bookmarks.html 1/bookmarks.html 176c176 < <DT><A HREF="http://google.com/search?q=%s" ADD_DATE="1010049100" LAST_MODIFIED="1010910011" SHORTCUTURL="g">gq</A> --- > <DT><A HREF="http://google.com/search?q=%s" ADD_DATE="1010049100" LAST_MODIFIED="1010049641" SHORTCUTURL="g">g</A> last_mod'd, and nothing else. Works fine now. No restart or anything.
I bet this it due to the bookmark name being 1 character. I change it back and it breaks again.
No, I thought that too when you posted those 1 character keywords and I tried them myself, and I was able to use them fine. So it's not 1 character keywords, at least not by themselves.
I changed the names of all the bookmarks, and they were working for a while... Installed a new build today and now they're no longer active. Similar to the search engine problem.
I have been seeing this too. Win98, Build 2002012203 currently, but I have been seeing it for at least a week and I update nightly builds almost daily. Some time ago my custom kewords stopped working. Yesterday I finally got around to doing something about it, and found this bug. Following the suggestions above, I changed the "Keyword" associated with each bookmark. In fact, I changed them, and then changed them back again so that I could go on using the keywords I was used to. This appeared to solve the problem. Unfortunately it did not occur to me to save the old version of the bookmarks. This morning, one of my 5 keywords had stopped working (I had not installed a new nightly in that time (I am 99% certain) but mozilla had crashed once or twice.). This time I did copy my bookmarks.html file before using the renaming trick. The procedure was: Exit Mozilla make a copy of bookmarks.html Start Mozilla Bring up bookmark properties for this bookmark Change the keyword from 'oed' to 'oeds' Click OK Bring up bookmark properties for this bookmark Change the keyword from 'oeds' to 'oed' Click OK check that the keyword now worked. exit mozilla. diff the saved bookmark file with the current one. As a previous person found, only one line had changed, and only in the expected way. ! <DT><A HREF="http://dictionary.oed.com/cgi/findword?query_type=word&queryword=%s&find.x=0&find.y=0" ADD_DATE="1006175961" LAST_VISIT="1011024899" LAST_MODIFIED="1011780591" SHORTCUTURL="oed" LAST_CHARSET="ISO-8859-1">oed</A> ! <DT><A HREF="http://dictionary.oed.com/cgi/findword?query_type=word&queryword=%s&find.x=0&find.y=0" ADD_DATE="1006175961" LAST_VISIT="1011880346" LAST_MODIFIED="1011880358" SHORTCUTURL="oed" LAST_CHARSET="ISO-8859-1">oed</A> By the way, all my custom keywords are in a subfolder under bookmarks called "Custom Keywords". There must be something else going on here. Is bookmark data cached anywhere? Are there some other files I could usefully do a before and after diff on if this happens again? Whilst I was writing this bug report I was testing out all my custom keywords, and some of them stopped working again and I had to rename them again, but I can't really add anythign useful beyond that vague statement.
My custom keywords have stopped working on OpenVMS too.
16 years ago
1.2 ? I normally use this feature tens of times a day since I found out about it ! Are things in such a bad state you can't revert to behaviour of a few weeks ago, where it was at least repeatable ? I'm really disappointed by this :(
I agree. I love this feature and really miss it. Can't we have it back?
I managed to get my custom keywords working again, though I don't know how long for. Previously I had the keyword keyword be the same as the keyword name. When I made these different, they started working again.
I tried what firstname.lastname@example.org did. was: Name=Keyword='google' changed to: Name='google kw' -> worked changed to: Name=Keyword='google' -> did not work changed to: Name='google!' -> worked
Agreed. It seems that only bookmarks with title == keyword don't work. You can even change the title/keyword while mozilla is running, and the keyword will start/stop working on the fly. Changing summary to match.
I'm still seeing all the symptoms I described in comment 9. checkout finish: Thu Mar 7 13:00:17 GMT 2002 In particular any other comments about 1-wide names or names same as the keyword are irrelevant to what I'm seeing. I'm still seeing the prefs corruption both with internet search and the enable internet keywords option, occasionally. This isn't a components.reg problem ...
I just recently discovered that any custom keyword will stop working if the title of the bookmark case-sensitively matches the keyword. So this one worked: BZ - bz But these did not: google - google dictionary - dictionary thesaurus - thesaurus I renamed my "google" bookmark to "Google" and left the keyword as "google" and it immediately started working again, so changing the case of that one letter worked around the problem. This was not a problem in Moz0.9.4 (NS6.2.1), if that helps at all. I vote for changing the summary to "Keywords don't work if they case-sensitively match the bookmark title" or something along those lines.
Eric A. Meyer: how about reading the comments ? in particular comment 9 and comment 22. As it happens, I've not been able to reproduce any keywords problems recently anyway, but the summary has been changed to what you suggest once already, and I changed it back again simply because that was /not/ the only case I was seeing problems with. In particular after the comments mentioning what you describe, I changed the names to not match, and still intermittently saw the problem.
Well, I did read the comments, but thanks for the suggestion. I'll retract my summary change proposal, in the hopes that will smooth any ruffled feathers; my failure to check the bug activity before posting was indeed wholly my fault. My observations in 0.9.9/Mac and 2002031308/Mac were that only case-sensitive keyword matches caused the custom keywords to stop working. Any change in case allowed them to work again. I figured that after a half-hour of testing various combinations in various builds and NS6.2.1 (for completeness' sake) that I ought to contribute what I'd found to the bug that seemed to be closest to the problem I was seeing. Apologies if I trod on any toes in the process.
Found this bug just before submitting this: --------------------- From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+) Gecko/20020406 BuildID: 2002040608 Trailings spaces in the keyword field will prevent the keyword from functioning. Reproducible: Always Steps to Reproduce: 1. Add a trailing space to any functioning bookmark keyword. 2. Enter the keyword into the url bar. 3. Remove the trailing space from the bookmark keyword. 4. Enter the keyword into the url bar. Actual Results: After adding the trailing space, mozilla fails to substitute the bookmark's url for the keyword. After removing the trailing space, mozilla resumes substituting the bookmark's url for the keyword. Expected Results: With or without trailing spaces, the keyword should be substituted with the bookmark's url.
Please Set the platform to All, I have the same problems with MacOS 0.1, Build 2002090309 I have defined a bookmark "http://bugzilla.mozilla.org/show_bug.cgi?id=%s" as said in the tips some where on Mozilla Site Making the name and the keyword different help, as said in comments
Platform -> All per comment 27.
I confirm that when the name and the keyword are different, it works
*** Bug 160265 has been marked as a duplicate of this bug. ***
Just ran into this (kinda) in Firebird 0.6.1. Imported all my Mozilla bookmarks, and the keywords are *listed* but won't work without being edited first.
Hm, slightly different problem I think - if there's *two* bookmarks with the same keyword, Mozilla (and Firebird) use neither and just do nothing.
*** Bug 144875 has been marked as a duplicate of this bug. ***
james: is the issue you had in comment 31 reproducible?
Very much so at the time; however, current Trunk Firefox seems to take the last one for a particular keyword, but I can't test the exact same thing (importing), only adding multiple bookmarks by hand.
Is this the same bug referred to here, or a new bug? In Firefox 18.104.22.168 running on WinXP latest service pack, when opening a new window, custom keywords typed into the location bar do NOT open the appropriate bookmarked site, but instead look up a .COM site using the keywords. In the original window, the custom keywords perform normally.
Ben: are you going to tackle this, or should I assign to default owners? Also, can we correct the bug summary to explain what is failing, and find someone to look at the code?
i don't think we ever got a reproducible test case. does anyone have one?
i don't think we ever got a reproducible test case. does anyone have one?
I just tried to duplicate several of hte various cases described and could not reproduce the situation in Firefox 22.214.171.124. Here are the cases I tried: * a normal bookmark having the same name as the keyword * a %s-style keyword having the same name as the keyword * using a one-character keyword for the above as well I use a one-character keyword quote often ("f" for Google Finance) and have not had any issues that I can recall in recent times. I do recall way back when that if I had had a previously-visited typo URL (e.g., http://sl.com/) I could not use "sl" as a keyword as long as that URL remained in my typed-locations history. However, that erroneous behavior seems to have vanished, possibly because browser.urlbar.autoFill is False in recent Firefox. However, I think that that misbehavior is different than what other users on this bug were reporting.
I was one of the people who experienced this problem way back when. I have not experienced it for years, and would have not problem seeing this bug resolved as worksforme.
jeremy (reporter): if you're still around, feel free to re-open if you can repro.