767939 - Editing a bookmark and changing URL drops tags

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, defect)

Description

[Perry Wagle]

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

Comment 1

[Perry Wagle]

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

Comment 2

[Marco Bonardo [:mak]]

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

Comment 3

[Perry Wagle]

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.

Comment 4

[Perry Wagle]

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.

Comment 5

[Marco Bonardo [:mak]]

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.

Comment 6

[Perry Wagle]

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

Comment 7

[Marco Bonardo [:mak]]

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

Comment 8

[Perry Wagle]

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.

Comment 9

[Perry Wagle]

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!

Comment 10

[Don Pellegrino]

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.

Comment 11

[Perry Wagle]

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

Comment 13

[ultrafox]

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.

Comment 14

[Perry Wagle]

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?

Comment 16

[Alice0775 White]

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

Comment 17

[fireattack [:fireattack]]

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).

Comment 18

[xorandor]

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.

Comment 19

[Asaf Romano (gone)]

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

Comment 20

[Marco Bonardo [:mak]]

Attachment: patch v1

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.

Comment 21

[Dietrich Ayala (:dietrich)]

Dataloss regression open for over a year (!).





PS: Hi guys! :D

Comment 22

[Dietrich Ayala (:dietrich)]

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

Comment 23

[Dietrich Ayala (:dietrich)]

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...

Comment 24

[Dietrich Ayala (:dietrich)]

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

Comment 25

[Marco Bonardo [:mak]]

(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 26

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/aa5a42f85d50

Comment 27

[:Gavin Sharp [email: [e-mail]]]

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

[Triage Comment]

Comment 28

[Marco Bonardo [:mak]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/ff9a57bf0950

Comment 29

[Tracy Walker [:tracy]]

Verified with latest builds on Nightly and Aurora