438252 - Editing bookmark's uri and then Tags, update tags for the old uri

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, defect, P1)

Description

[Yeef]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

When organizing bookmarks if you edit the address of a bookmark, then edit the tag information the address change will be updated, but not the tag info. 

Editing the bookmark title and tag at the same time works fine.



Reproducible: Always

Steps to Reproduce:
1. Create a bookmark
2. Go into organize bookmarks and select the bookmark
3. edit the URL of the bookmark
4. without changing your selection on the bookmark list, edit the tags of the bookmark
5. Changing your selection or closing the bookmark window will save the updated address info, but not the updated tag info.
Actual Results:  
The address was saved, but not the tag.

Expected Results:  
Saved the tag information as well.

Comment 1

[Alice0775 White]

I do not know Places well, but suggest a patch as follows.

In gEditItemOverlay:

onLocationFieldBlur
 function EIO_onLocationFieldBlur() {
    var uri;
    try {
      uri = PlacesUIUtils.createFixedURI(this._element("locationField").value);
    }
    catch(ex) { return; }
    if (!this._uri.equals(uri)) {
      var txn = PlacesUIUtils.ptm.editBookmarkURI(this._itemId, uri);
      PlacesUIUtils.ptm.doTransaction(txn);
+      this._uri =uri;
    }
  

Comment 2

[Daniel Holbert [:dholbert]]

I can't reproduce this using today's nightly mozilla-central build, on Linux.

In Step 5, I've tried (separately) changing selection and closing the window, and in both cases, the tags *and* location updates are saved.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081019 Minefield/3.1b2pre

Can anyone still reproduce this? (particularly on Windows, as that's the OS it was originally filed under)  If not, it should be closed as WORKSFORME.

Comment 3

[Alice0775 White]

It is still reproduced.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081020 Minefield/3.1b2pre

Comment 4

[Alice0775 White]

I can reproduce with ubuntu 8.04.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081020 Minefield/3.1b2pre

As for me, comment #2 is not believed.

Comment 5

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Exactly what i see, is that the tag is saved for the old uri value, so your fix could make sense.
Alice, could you cook it up in a patch please?

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to comment #4)
> As for me, comment #2 is not believed.

Yup, disregard comment 2 -- I can reproduce the bug now, using that same build ID.  I'm not sure why I couldn't reproduce it before -- sorry for the confusion.

Specifically, I see this behavior:
 - the existing bookmark gets the new URI & old tags.
 - a new bookmark is created (in "Unfiled Bookmarks") with the old URI & new tags.

Comment 7

[Dietrich Ayala (:dietrich)]

Attachment: fix

i was able to reproduce the bug, as well as confirm that the fix works.

Comment 8

[Mike Connor [:mconnor]]

Comment on attachment 347002 [details] [diff] [review]
fix

>diff --git a/browser/components/places/content/editBookmarkOverlay.js b/browser/components/places/content/editBookmarkOverlay.js

>+      this._uri =uri;

nit: space after = please.

Comment 9

[Dietrich Ayala (:dietrich)]

http://hg.mozilla.org/mozilla-central/rev/ea8206021f3f

Comment 10

[Tracy Walker [:tracy]]

verified: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b2pre) Gecko/20081112 Minefield/3.1b2pre