User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

• Go on native bookmark sidebar of bookmarks library, create a bookmark with tag "testtag", title = "testbookmark", url = "http://test.com/".
• Use webextension API browser.bookmarks.update(), or an add-on such as Bookmark search PLus 2, to change the URL to "http://www.test.com/"
• Variant = change it to "http://test.com/testpath/".

Actual results:

• In both cases, the tag is not showing anymore on the bookmark !!

Expected results:

• The tag should still be present

Note also that:

• If you change the URL back to "http://test.com/", in both cases, the tag shows again ! (so it is not list .. and strangely enough it seems to be linked to the URL then ?!?)

Because this bug's Severity is normal and has not been changed, and this bug's priority is -- (none,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

So in the Firefox UI we manage this through PlacesTransactions, but WebExtensions directly use the bookmarking API. This should indeed be managed in the bookmarking API as bug 960468 suggests, but for that we must first fix tags handling.

This looks like a duplicate of bug 1388890.

Interesting, so the above two would confirm that tags are associated to URLs and not to bookmarks ... not intuitive nor documented as such, e.g.
-> https://support.mozilla.org/en-US/kb/categorizing-bookmarks-make-them-easy-to-find?redirectlocale=en-US&redirectslug=Bookmark+Tags
-> https://support.mozilla.org/en-US/kb/bookmarks-firefox

Everything in docs, as well as in behavior of the native bookmark sidebar handling of tags, appears to tell users that tags are on bookmarks.
Which by the way is more intuitive .. after all, URLs can change (and often do), while their content / topic doesn't. Purpose of having a bookmark for an average user being a way to get back quickly to content, by extension, tagging is mentally seen as being on content, and not on an address to that content at some moment in time.

Btw, since I seem to remember from bug 1396364 that tags are like folders of bookmarks, I have difficulties in seeing how there is a link between tags and URLs. Or what am I missing ?

(In reply to aafn from comment #4)

Everything in docs, as well as in behavior of the native bookmark sidebar handling of tags, appears to tell users that tags are on bookmarks.

You can have multiple bookmarks pointing to the same url, and then users likely expect all of those bookmarks to have the same tags, not just one of them. And that's why tags are on urls, even if they are a concept for bookmarks.

I agree with Marco - I often have multiple bookmarks pointing to the same URL, and having the same tags in each bookmark is very helpful.

For example, I might have a bookmark folder F1 for project P1 that contains a bookmark B1, to which I have assigned multiple tags. Some time later, I create a folder F2 for project P2, and I add to it a bookmark B2 (which points to the same URL as B1). The fact that I don't have to assign tags to B2, since it already has the tags I assigned to B1, makes this process much easier.

Looks like a duplicate of bug 1440988.