Closed Bug 91945 Opened 24 years ago Closed 22 years ago

Custom Keyword problem until restart

Categories

(SeaMonkey :: Bookmarks & History, defect, P5)

Product:
SeaMonkey
Component:
Bookmarks & History
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: otaylor, Assigned: bugs)

References

Details

If I create a custom keyword with %s substitution with the following steps, it doesn't work property until I restart the browser: * Go to www.altavista.com and enter a search (say "mozilla") * Bookmark the result using Bookmarks/Add Bookmark * Bring up the "Manage Bookmarks" dialog, find the newly added bookmark and edit its properties * Enter "altavista" in the custom keyword field, and edit the URL to replace the search term with %s * Close the bookmark editor If I try to use the custom keyword by entering "altavisa mozilla", then it doesn't recognize the keyword at all. "altavista" by itself goes to the unedited URL. Quitting the browser and restarting makes the new custom keyword work properly.
This is using Mozilla 0.9.2 (mozilla-0.9.2-7 from Red Hat Rawhide)
I noticed this a few days ago on Linux and assumed it was already reported. A search of all bugs with "custom keyword" had nothing similar to this so I'm assuming this is not been filed yet. Marking NEW. Can someone confirm this on Windows/Mac?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirming on 2001080114 on Win2K. Changing OS to ALL.
OS: Linux → All
*** Bug 101438 has been marked as a duplicate of this bug. ***
*** Bug 101520 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: --- → Future
This was fixed in 0.9.4 on WinNT (as far as I can tell) but it is broken again in 0.9.5. Arrggghhh... and I *really* like this feature. Oh well, back to 0.9.4 for me. :( Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.5) Gecko/20011011 IBM ThinkPad 600e 256MB RAM 6GB HD Windows NT 4 (sp6a) 1024x768x64k
Hmmm...what I meant to say was that the bookmark keyword no longer works in 0.9.5 at all! Even if I reboot! :( Is this a different issue? Sorry for the multiple comments...
Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter email notifications caused by this by searching for 'ilikegoats'.
Assignee: ben → pchen
Status: ASSIGNED → NEW
Mass move Ben's bugs dumped on me marked future with p5 to get off my untriaged radar. You can filter out this email by looking for "ironstomachaussie"
Priority: -- → P5
Ummm...I got my bookmark keywords working properly so my previous comments are not valid. However, I did confirm that this bug is alive on my system: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.5) Gecko/20011011 WinNT 4.0 (sp6a) 228MB RAM 333 PIII
mass reassign of pchen bookmark bugs to ben
Assignee: pchen → ben
removing self from cc list
Modifying an existing custom keyword bookmark also has this behavior. The previous value of the bookmark continues to be used when the keyword is typed into the location bar. I suspect that keywords are determined at startup, and are not updated as changes are made later.
For me the Case is if even worse, I couldn't change the keyword for a once created bookmark. The old Keyword and naming is still used, also after restarting the browser. Also if the Rename the Bookmark it is still reverted to the old name. I'm using Mozilla Trunk September 1st build
i can't repro this on win32 1.2a. maybe it has been fixed?
Both symptoms (new keyword definition and modified keyword) seem to work correctly in N7 (final) for Windows.
I have tested this using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030502 and it works for me. I also believe I read somewhere that there has been major bookmark code landed a while ago.(post 1.4a) Reporter (and the rest) you please retest with a more recent build and see if the problem persist. If the problem is gone,please resolve this bug as works-for-me
marking wfm
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.