"Cut" operation in Library or sidebar acts as "Copy"

RESOLVED FIXED

Status

()

Firefox
Bookmarks & History
--
minor
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: George Carstoiu, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [5b5])

(Reporter)

Description

6 years ago
Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0

An object that is cut (using either CTRL+C or the contextual menu) can be pasted several times - cut acts as though copy was performed.

Reproducible:always

Steps to reproduce:
 1. Go to Library
 2. Select a folder and use the Cut option
 3. Paste it in several locations

Actual results:
 - the object can be pasted several time

Expected results:
 - the object can be pasted just once
(Reporter)

Comment 1

6 years ago
Issue is present ever since Firefox 3.6.16
Whiteboard: [5b5]
(In reply to comment #0)
> Actual results:
>  - the object can be pasted several time

I'd rather expect this Behavior as other Applications do, no?
(Reporter)

Comment 3

6 years ago
(In reply to comment #2)
> (In reply to comment #0)
> > Actual results:
> >  - the object can be pasted several time
> 
> I'd rather expect this Behavior as other Applications do, no?

 Exactly - an item cannot be pasted to infinity if it was cut - logically it should be pasted only once
I think this happened forever, not only from 3.6.
Cut has a series of problems that should be solved, it was indeed implemented as "copy to clipboard and delete" for lack of time in the beginning.
(In reply to comment #3)
> > I'd rather expect this Behavior as other Applications do, no?
> 
>  Exactly - an item cannot be pasted to infinity if it was cut - logically it
> should be pasted only once

Errm, my Point was that other Application bahave the same by allowing to paste a cut String multiple Times.
Well, Windows Explorer allows to paste just once after a cut, and it seems to make sense. I'm not sure about OS X or Linux.
Text handling is different as you said, but I guess that in this case the filemanager behavior is more consistent with the Library experience.
may be fixed by bug 416459
Depends on: 416459

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.