The default bug view has changed. See this FAQ.

A bookmark’s tag disappearing when bookmark Cut and Paste to other bookmark folder

VERIFIED FIXED in Firefox 7

Status

()

Firefox
Bookmarks & History
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: Dimitri, Assigned: mak)

Tracking

({dataloss})

6 Branch
Firefox 7
x86_64
Windows 7
dataloss
Points:
---

Firefox Tracking Flags

(firefox6 wontfix)

Details

(Reporter)

Description

6 years ago
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.
(Reporter)

Comment 1

6 years ago
Correction. Cut and Paste. Not Copy.
(Reporter)

Updated

6 years ago
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
(Reporter)

Comment 2

6 years ago
See Bug 682513
(Assignee)

Updated

6 years ago
Component: General → Bookmarks & History
Keywords: dataloss
QA Contact: general → bookmarks
(Assignee)

Comment 3

6 years ago
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.
(Assignee)

Updated

6 years ago
Duplicate of this bug: 682513
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.
(Reporter)

Comment 7

6 years ago
Can someone confirm it on current FF6?
Upgrading to FF7beta2 fixing it.
(Assignee)

Comment 8

6 years ago
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: 6 years ago
status-firefox6: --- → wontfix
Depends on: 416459
Resolution: --- → FIXED
Target Milestone: --- → Firefox 7
(Reporter)

Updated

6 years ago
Status: RESOLVED → VERIFIED
Resolution: FIXED → WONTFIX
(Assignee)

Comment 9

6 years ago
wontfix? this is fixed on trunk, wontfix on versions before 7 (As indicated by the tracking flags)
Resolution: WONTFIX → FIXED
(Reporter)

Comment 10

6 years ago
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.
(Assignee)

Comment 11

6 years ago
(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.