"Copy > Cut element" breaks existing semantics established for decades (should be visually cut from DOM Tree)
Reported by
nex...@gmail.com,
Mar 26 2016
|
|
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2690.0 Safari/537.36 Steps to reproduce the problem: 1. Open Context menu on an DOM element in the Elements panel 2. Go to Copy > Cut element 3. Paste element somewhere What is the expected behavior? The element being cut should not be in the tree between steps 2 and 3. What went wrong? "Cut element" breaks semantics that user expects, thus surprising the developer. User expects element to be removed from tree and be put into some storage temporarily (mental model). They paste the element somewhere, thus expecting storage to be emptied with the element they had previously cut. Did this work before? No Chrome version: 51.0.2690.0 Channel: n/a OS Version: OS X 10.10.2 Flash Version: Shockwave Flash 21.0 r0 For the UI element I am referring to, please refer to cut-culprit.png I propose a DevTools-specific Clipboard. This could be made obvious in some way (see cut-proposal.png)
,
Apr 4 2016
I have been a windows and mac user for more than 8 years. I have no idea what you are talking about mac world. But cmd+x works exactly like ctrl-x on either platform for me on all applications. |
|
►
Sign in to add a comment |
|
Comment 1 by pfeldman@chromium.org
, Mar 28 2016