This could be done having insertTags,removeTags properties in the input object, unfortunately just having "tags" would not allow to untag easily, since it would require the caller to first fetch the tags list, and then pass back an updated list, that sounds inefficient.
Bug 1388890 seems related to this. Please consider the use case of only updating the URL for a bookmark and preserving all tags.
In my workflow, I am changing tags all the time to indicate when to look next, what place, etc. If that took under a second, that'd be great, I think. Up to several hundred a day adds up. (Hence my very keen interest in automating parts of this workflow). I also change URL's for a particular bookmark to track where the (wiki, usually) page is today. The collection of tags I have for it is astoundingly critical, and very hard to recreate from memory of the bookmarks (up to multiyear) lifetime. Except by typo, I very rarely delete all the tags. Usually when the link is "DEFINITELY DEAD" (like gone for years), no longer relevant, or a wikipage moving or being removed. People I've met have expressed interest in tagging and querying. If tags aren't used much, it because the default miserable experience has been eroding for a decade. But thank you extremely much for working on them now!
(In reply to Dan Wallis from comment #1) > Bug 1388890 seems related to this. Please consider the use case of only > updating the URL for a bookmark and preserving all tags. would it be ok to set the same tags on both old and new url, if both are bookmarked?
Right now the tags follow the bookmark, not the URL. For me, anyway, the tags are part of the bookmark, not the URL. What's the reasoning for attaching to the URL, which get redirected, changes with the seasons, etc? I have daydreams about having the bookmark URL chase the redirects, but I half suspect that that is wrong headed.
(In reply to Marco Bonardo [::mak] from comment #3) > would it be ok to set the same tags on both old and new url, if both are > bookmarked? Yes, that is the behaviour of the current built-in bookmark manager. I'd expect the API to behave the same in this case. (In reply to Perry Wagle from comment #4) > Right now the tags follow the bookmark, not the URL. The underlying implementation is that URLs are tagged, not bookmarks (hence bug 1388890). The built-in bookmark manager hides this implementation detail from the user by behaving as if bookmarks are tagged, so bookmarks remain tagged when the URL gets updated. (Under the hood, I understand that the new URL gets tagged, and any newly-orphaned tag-URL-mappings get cleaned up.)
You need to log in before you can comment on or make changes to this bug.