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.
Correction. Cut and Paste. Not Copy.
Summary: A bookmark’s tag disappearing when bookmark copied and paste to other bookmark folder → A bookmark’s tag disappearing when bookmark Cut and Paste to other bookmark folder
See Bug 682513
Component: General → Bookmarks & History
QA Contact: general → bookmarks
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.
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!
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.
Can someone confirm it on current FF6? Upgrading to FF7beta2 fixing it.
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.
Assignee: nobody → mak77
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
status-firefox6: --- → wontfix
Depends on: 416459
Resolution: --- → FIXED
Target Milestone: --- → Firefox 7
wontfix? this is fixed on trunk, wontfix on versions before 7 (As indicated by the tracking flags)
Resolution: WONTFIX → FIXED
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.
(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 mozilla.dev.planning for wider discussion.
You need to log in before you can comment on or make changes to this bug.