Closed Bug 438252 Opened 14 years ago Closed 13 years ago

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


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




Firefox 3.1b2


(Reporter: genchi_x, Assigned: dietrich)


(Keywords: dataloss, verified1.9.1, Whiteboard: [has approval])


(1 file)

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.
I do not know Places well, but suggest a patch as follows.

In gEditItemOverlay:

 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);
+      this._uri =uri;
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.
It is still reproduced.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081020 Minefield/3.1b2pre
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.
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?
Assignee: nobody → alice0775
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: Tag edits do not save when editing bookmark address at the same time. → Editing bookmark's uri and then Tags, update tags for the old uri
Target Milestone: --- → Firefox 3.1
(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.
Version: unspecified → Trunk
Flags: blocking-firefox3.1?
Severity: normal → major
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Keywords: dataloss
Priority: -- → P1
Target Milestone: Firefox 3.1 → Firefox 3.1b2
Attached patch fixSplinter Review
i was able to reproduce the bug, as well as confirm that the fix works.
Assignee: alice0775 → dietrich
Attachment #347002 - Flags: review?(mano)
Whiteboard: [has patch][needs review mano]
Comment on attachment 347002 [details] [diff] [review]

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

>+      this._uri =uri;

nit: space after = please.
Attachment #347002 - Flags: review?(mano) → review+
Whiteboard: [has patch][needs review mano] → [has approval]
Closed: 13 years ago
Resolution: --- → FIXED
verified: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b2pre) Gecko/20081112 Minefield/3.1b2pre
Keywords: verified1.9.1
Keywords: fixed1.9.1
You need to log in before you can comment on or make changes to this bug.