Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 ID:20160705030222 CSet: c9a70b64f2faa264296f0cc90d68a2ee2bac6ac5 When you update the URL of a bookmark which has a keyword set, the latter is no longer displayed inside the Library. Steps: 1. Browser to a page, bookmark it and set a keyword 2. Open the Library 3. Select the bookmark, and change the URL 4. Switch to another bookmark and go back to the original one 5. Observe that the keyword is no longer shown but still works This goes at least back to Firefox 49.0 and maybe even earlier.

Hm, it even looks like that the keyword is still bound to the former URL and does not resolve to the updated one.

[Tracking Requested - why for this release]: Asking for tracking because of that behavior we end-up in data inconsistency. A workaround for now seems to be that you have to re-set the keyword for the new URL. Until then the old URL will be opened when using it. It would be good to get a regression range for this bug.

> A workaround for now seems to be that you have to re-set the keyword for the new URL. This workaround doesn't work for me. Attempts to re-set the keyword for the new URL fail: I can type it in, but then it goes back to blank as soon as I focus a different bookmark. This means I no longer have a sane way to do code search (tried to update my code search URLs from mxr today), which is rather a blocker for getting anything done. :(

Related to bug 1150678. Same regression, same issue.

Per advice from mak, got things back by deleting all the old bookmarks, running places maintenance, and recreating all the bookmarks. Was a huge pain. :(

So it regressed via bug 1125115.

Tracking 49/50+ for this regression which can cause users to have data inconsistency.

(In reply to Boris Zbarsky [:bz] from comment #5) > Per advice from mak, got things back by deleting all the old bookmarks, > running places maintenance, and recreating all the bookmarks. FWIW, we run maintenance once a week on normal profiles, so after a week in the worst case, the problem would be fixed. Clearly not a great workaround, but that's what we got so far. The reasons this has not been prioritized so far: * Keywords are used by a small percentage of technical users (mostly devs) * The bug is "fixed" in some days, as soon as maintenance runs * there's a plan to convert keywords to custom search engines, that needs resources, so it's not worth spending too much time on the current implementation * The right fix would involve completing the Async Places Transactions project that is stuck at about 80% completion after Mano left. We can at best have a workaround, or we need to schedule time to complete the project.

Setting fix-optional for 49 based on comment 8.

(In reply to Marco Bonardo [::mak] from comment #8) > * The bug is "fixed" in some days, as soon as maintenance runs Not my experience. I modified the url of a keyword search. A day a two ago. It showed the wrong url. Now I checked it again: The keywords disappeared completely from the bookmarks.

This bugs apply if you want to change the url, the keyword, or if you delete the bookmark. None of those changes are reflected. The maintenance that you mention is it run by the program? If so wouldn't at least be a good idea to put on the menu a button that says fix bookmarks/check bookmarks integrity that triggers that event when you want it to trigger? (if you dont want to make it visible for non tech savvy users put it as a dev tool or whatever)

@iraola887 No software should ever add an option anywhere with **workarounds** for things that should be fixed without any action from the user. You can, however, use this extension: https://addons.mozilla.org/firefox/addon/places-maintenance/

@budaeuforico+mozilla or Hide my Email Still think it's a better response than saying wont fix cause not many people use it when it's an open source program with so many volunteers (inside the org and outside of it); people which might jump on it given the opportunity to do so. Specially when the ideals of the org are based on creating "An Internet that truly puts people first, where individuals can shape their own experience and are empowered, safe and independent." while on the other hand say "people don't know much so we should make decisions for them". BTW I Tested the add-on and It didn't solve the issue. The ghost keyword/bookmark still exist.

this is not a wontfix, it's just a bug we didn't find the time to fix yet. Being a bug, there should be no "workaround" added to the product, at that point it would be better to spend time on a fix. The workaround is just the fact we do database maintenance, and that seems to also fix this issue when it runs (until the next change).

I'm waiting for a full week now to see if the database maintenance task gets triggered. So far it looks like that it has not been done. Also I want to note that when you are using Firefox Accounts to sync bookmarks, the keywords are not synced! They plainly don't work at all on the other connected machines.

In my case waiting more than a week didn't fix it. I "had" "mya" as a keyword for a search I deleted that bookmark and created an other one with "mal" for keyword and a different url I still can type "mya" to do a search even though that keyword shouldn't exist anymore.

Too late to fix in 50.1.0 release