Task #42014

Story #44957: Reliable clipboard and content element handles

Cut and Paste is not working reliably

Added by Christopher Hlubek about 9 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Must have
Assignee:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
#1

Updated by Mattias Nilsson almost 9 years ago

  • Assignee set to Mattias Nilsson
#2

Updated by Mattias Nilsson almost 9 years ago

  • Status changed from New to Accepted
#3

Updated by Mattias Nilsson almost 9 years ago

During the testing of the cut/copy and paste methods it was not possible to recreate the errors. I have tried in the latest version of Google Chrome and Firefox.

The icons was behaing as expected, the content was put on the correct position and the content was rendered as it was before the action.

#4

Updated by Mattias Nilsson almost 9 years ago

  • Status changed from Accepted to Needs Feedback
#5

Updated by Christopher Hlubek almost 9 years ago

I'll do another test today.

#6

Updated by Christopher Hlubek almost 9 years ago

I still get errors:

(in ember-0.9.7.js:16440)

Uncaught Error: Cannot perform operations on a Metamorph that is not in the DOM.

And the buttons do not work reliably for me (sometimes a click is just not registered) and the paste icon is not shown, even if cut / copy is shown as pressed.

If I unpress the cut icon after the error I get another exception:

DEPRECATION: Something you did caused a view to re-render after it rendered but before it was inserted into the DOM. Because this is avoidable and the cause of significant performance issues in applications, this behavior is deprecated. If you want to use the debugger to find out what caused this, you can set ENV.RAISE_ON_DEPRECATION to true.
#7

Updated by Christopher Hlubek almost 9 years ago

One thing is a UI issue: the Ember action is bound to the icon instead of the button, this can be changed easily. Another thing is that after a successful cut / paste a page reload occurs and the bugs appear.

#8

Updated by Christopher Hlubek almost 9 years ago

It seems that the Ember view is not removed after the page gets reloaded. Which causes problems, because Ember bindings are still active and are triggered if the cut button is pressed, so the not visible handles will try to update the DOM, which is detected and complained about in Metamorph.

We should try to correctly remove any Ember view on a reload of a content element.

#9

Updated by Christopher Hlubek almost 9 years ago

I tried to remove all Ember views after a page load, but that doesn't help (I don't really understand why).

The only solution I see is to change the clipboard handling:

  • Use one handles view for all content elements
  • Bind the view to the selectedNode
  • Re-position the view on selection of a node (could be observed)
  • With proper bindings the view should update the button states depending on the selected node or clipboard content
#10

Updated by Aske Ertmann almost 9 years ago

#7 is fixed with https://review.typo3.org/#/c/16317/

I can reproduce the problems Christopher is having. Before pasting an element I sometimes can have something cut/copied but unable to paste it anywhere, but where i cut/copied it. After pasting an element I get the same exception "Uncaught Error: Cannot perform operations on a Metamorph that is not in the DOM." and the same when uncutting/uncopying..

I hope we can do something else to get rid of the views that has been removed, since this will probably not be the only place we'll have that problem..

I googled "emberjs Cannot perform operations on a Metamorph that is not in the DOM" and there are some stuff we could try..

#11

Updated by Christopher Hlubek almost 9 years ago

Aske Ertmann wrote:

I hope we can do something else to get rid of the views that has been removed, since this will probably not be the only place we'll have that problem..

What about my idea to change the handles to only one Ember view that gets assigned to a node on selection? I feel this could be a more robust solution especially with dynamic reloading of content.

#12

Updated by Mattias Nilsson over 8 years ago

  • Assignee deleted (Mattias Nilsson)
#13

Updated by Christopher Hlubek over 8 years ago

  • Parent task changed from #41101 to #44957
#14

Updated by Christopher Hlubek over 8 years ago

  • Assignee set to Rens Admiraal
  • Priority changed from Should have to Must have
#15

Updated by Mattias Nilsson over 8 years ago

  • Status changed from Needs Feedback to Resolved
  • Assignee deleted (Rens Admiraal)

This issue is solved in: https://review.typo3.org/#/c/19306/

#16

Updated by Mattias Nilsson over 8 years ago

  • % Done changed from 0 to 100
#17

Updated by Jacob Floyd over 8 years ago

I just noticed a comment in Application.js1 that suggests that the workaround might not be necessary once this bug is fixed. Now this issue is fixed, is the hack in [1] necessary?

[1] https://git.typo3.org/FLOW3/Packages/TYPO3.TYPO3.git/blob/HEAD:/Resources/Public/JavaScript/Content/Application.js#l299

Also available in: Atom PDF