User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20100101 Firefox/13.0.1 Build ID: 20120614114901 Steps to reproduce: (!) click the star in the url field to edit bookmark (or the mass bookmark editor) (2) edit the location (URL) Actual results: find that the bookmark now exists with the original tags CLEARED Expected results: It should have kept the tags with the new URL on the same bookmark

This is something I do all the time. Losing the tags is a disaster. It worked up to FF13.

you are tagging an url, if you change url you lose the tags, that's indeed expected...

This error started in ff13. It is not expected to lose the tags for the SAME bookmark when it changes its URL due to redirects, etc. I use tags extensively. I change URL's frequently. This error is a disaster for me.

If the user wants the tags deleted, then they can do that. If the user wants to keep the tags, then this new error makes that very difficult and error prone.

Honestly shouldn't be a new behavior, it's how the system was designed from the beginning. The fact you tag a bookmark doesn't matter, you are actually just tagging its url. So it's strange that it may differ in Firefox 13, but I can't exclude some change had an impact there, we'll have to check.

regression from here: https://bugzilla.mozilla.org/show_bug.cgi?id=421364

confirming for investigation, my guess is a regression from bug 728230.

Any news on when this will be fixed? I'm currently suffering through changing the URL's on three dozen bookmarks. At 2 minutes apiece, this is a very costly operation. Deleting the old bookmark, and hand-copying the 20 tags per item takes a while. Used to take about 5 seconds per.

8) I just now lost a bunch of bookmark tags because I was tired and got confused about what order to do things when RENAMING bookmark URLs. A simple task made much more complicated by this bug. I have to create a new bookmark for the new location and hand copy all the information over. A tedious, error-prone task, that it would be nice if the computer would do for me, like it used to. A bookmark has a name, location, folder, and tags. I cannot imagine why you would want to throw out the tags when you change the location. Its the same bookmark. URLs (locations) change all the time! But it the same bookmark! Really! Since I reported this bug, the look of the bookmark editor has changed yet again, but none of the long standing bugs in the functionality have been touched. Oh come-on, please? Some functionality! Thanks!

I confirm that this bug persists in Firefox 17.0.1 on Microsoft Windows 8 64-bit when edits are performed using the dialog shown via CTRL+SHIFT+B. I suspect that Perry Wagle's Comment 9 succinctly describes the root cause of this issue. The user's mental model when performing an edit is that there exists an underlying (invisible but conceptually tangible) bookmark entity which is expressed by Name, Location, Tags, Keyword, and Description properties. One implementation of this model would be for a bookmark entity to have a primary key that is independent of the Location property's value. Instead, it appears that Firefox bookmarks use the Location value as the primary key. Thus, when the Location's value changes the invisible but conceptually tangible bookmark entity is now different, to the surprise of the user. Whether the implementation uses a Location or a hidden primary key should be uninteresting. The main cause of problems is that when the Location is changed, the other property values do not move from the bookmark with Location A to the bookmark having Location B. The UI fails to express this, since a modification to the Location field does not clear the values from the other fields even though the change leads to those data being lost.

Just noticed that a bookmark stays in its folder when changing the location.

Confirming that this issue persists in Firefox 19.0.2. This behaviour is unexpected to the average user; the user may continue to edit bookmarks for quite awhile, losing tags, until they notice that the entire group of tags they previously edited now have no tags. Quite frustrating to have to go back and (1) figure out which bookmarks are affected, and (2) manually re-enter tags.

I use tags heavily. Blogs and other RSS, etc sites regularly change the URL to the same article that I have bookmarked. This bug makes it a lot harder and error-prone to update the bookmark (title, tags, folder, etc) to the new URL. Currently, I have about 100 pages in my wiki that I want to change the URLs for. Each bookmark has about 10 tags. How do you suggest I do this without losing a day and introducing errors instead of 15-30 minutes and almost no errors? It's easy to delete tags. Its hard to keep them. Why make the easy easier and the hard harder?

After edit URl and select another bookmark, the following error shown in the Error console] NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsITransactionManager.doTransaction] @ resource://gre/modules/PlacesUtils.jsm:1906

Can you please fix this bug? VERY annoying when you're replacing your bookmarks with updated/changed URLs (changing domain of a site is very common nowadays).

I just wanted to report the same bug for Fx26, but now I see that it is not fixed for over 1 year... (I'm new to Firefox) I've managed to find a workaround how to edit URL while keeping the tags (I know those steps are crazy and it's easier just to ctrl+c/v tags): 1. edit URL location 2. (while not closing bookmark) click name or keyword or description field (or the bookmark list, but be sure not to select another bookmark) 3. click location field again 4. click tag field 5. finally click name field again Now the fun begins if we skip step 3 and/or step 2. If we do than Firefox creates by self a duplicated bookmark where its name field is set to location without "https?://"... This is obvious bug.

The cause is a typo in PlacesUtils: this.item.uri = PlacesUtils.bookmarks.getBookmarkURI(this.item.id); ... PlacesUtils.tagging.tagURI(this.new.URI, this.item.tags); this.new.URI should be this.new.uri

The test is a little dumb, since the original test was already, and I think it's not worth rewriting or cleaning it, since you are rewriting the transactions manager and making a new test for it.

Dataloss regression open for over a year (!). PS: Hi guys! :D

Actually, canceling NI since I'm still a peer in this module and can review it ;)

Comment on attachment 8361037 [details] [diff] [review] patch v1 r=me. glad to hear the transaction manager is being async-ified! Would love to see this make it in before the merge...

Tiny low-risk fix for dataloss regression - would be great to see this ship earlier than 29 if possible.

(In reply to Dietrich Ayala (:dietrich) from comment #24) > Tiny low-risk fix for dataloss regression - would be great to see this ship > earlier than 29 if possible. Yep, considered it's basically a typo fix... I'll request approval. Thanks for the review, you are always more than welcome! https://hg.mozilla.org/integration/mozilla-inbound/rev/aa5a42f85d50

Comment on attachment 8361037 [details] [diff] [review] patch v1 [Triage Comment]

Verified with latest builds on Nightly and Aurora