Last Comment Bug 682512 - A bookmark’s tag disappearing when bookmark Cut and Paste to other bookmark folder
: A bookmark’s tag disappearing when bookmark Cut and Paste to other bookmark f...
: dataloss
Product: Firefox
Classification: Client Software
Component: Bookmarks & History (show other bugs)
: 6 Branch
: x86_64 Windows 7
-- normal (vote)
: Firefox 7
Assigned To: Marco Bonardo [::mak]
: Marco Bonardo [::mak]
: 682513 (view as bug list)
Depends on: 416459
  Show dependency treegraph
Reported: 2011-08-26 22:54 PDT by Dimitri
Modified: 2011-08-31 14:38 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Dimitri 2011-08-26 22:54:37 PDT
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0
Build ID: 20110811165603

Steps to reproduce:

Open All bookmarks manager – Ctrl-Shift-B
Right click Copy on a bookmark.
Move to other bookmark folder.
Right click Paste.

Actual results:

Bookmark’s Tag cleared.

Expected results:

Bookmark’s Tag should stay.
Comment 1 User image Dimitri 2011-08-26 22:57:32 PDT
Correction. Cut and Paste. Not Copy.
Comment 2 User image Dimitri 2011-08-26 23:14:37 PDT
See Bug 682513
Comment 3 User image Marco Bonardo [::mak] 2011-08-27 01:04:41 PDT
one interesting point is that CUT has been reimplemented correctly in Firefox 7, so would be interesting to know if current beta is affected by this bug. regardless, should be investigated.
Comment 4 User image Marco Bonardo [::mak] 2011-08-27 01:05:33 PDT
*** Bug 682513 has been marked as a duplicate of this bug. ***
Comment 5 User image Mihaela Velimiroviciu (:mihaelav) 2011-08-30 07:15:03 PDT
Build identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20100101 Firefox/7.0 (beta 2)
Build identifier: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:9.0a1) Gecko/20110829 Firefox/9.0a1 (nightly)

Verified the issue as described on the 7.0 beta 2 and latest nightly and could not reproduce it: when moving a bookmark from one folder to another the bokmark's tags are persisted.

Reporter, are you still able to reproduce this issue? Are there other STR for this?

Thank you!
Comment 6 User image Trif Andrei-Alin[:AlinT] 2011-08-30 07:18:09 PDT
Mozilla/5.0 (Windows NT 6.1; rv:9.0a1) Gecko/20110829 Firefox/9.0a1
Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0 (beta 2)

It isn't reproducible on these builds.
Comment 7 User image Dimitri 2011-08-30 14:40:34 PDT
Can someone confirm it on current FF6?
Upgrading to FF7beta2 fixing it.
Comment 8 User image Marco Bonardo [::mak] 2011-08-31 05:27:36 PDT
before firefox 7 doing a cut was:
- copying the entry
- removing the bookmark
- pasting the copied entry

Copy creates a new entity, thus it doesn't preserve tags since it's a different bookmark (even if pointing to the same uri), this may be suprising but it's part of the fact we allow to have multiple bookmarks for the same uri in different positions.

Starting from firefox 7 we don't use anymore copy to do cuts, we instead do real bookmarks moves, and tags are correctly preserved.

This bug is thus fixed by bug 416459 from Firefox 7 on, we won't fix it in previous versions, since the patch would not satisfy the stability criteria.
Comment 9 User image Marco Bonardo [::mak] 2011-08-31 11:41:13 PDT
wontfix? this is fixed on trunk, wontfix on versions before 7 (As indicated by the tracking flags)
Comment 10 User image Dimitri 2011-08-31 14:18:28 PDT
It may be fixed for You, developer working on beta version. But in real world this bug is NOT FIXED and causing data (and human time) loss on the current, used by mullions of people program of Yours - Firefox 6.
Comment 11 User image Marco Bonardo [::mak] 2011-08-31 14:38:40 PDT
(In reply to Dimitri from comment #10)
> It may be fixed for You, developer working on beta version.

We have clear rules on managing bugs, they are considered fixed when they are fixed on trunk, since we have to know when a specific fix made the product. Tracking flags for older versions exist for a reason, indeed status-firefox6 is set to wontfix, while target milestone is set to Firefox 7.
If you disagree with our approach, you should post your suggestions in for wider discussion.

Note You need to log in before you can comment on or make changes to this bug.