Ticket #338 (closed Bug: fixed)

Opened 18 months ago

Last modified 14 months ago

Drag & drop do not honor ForcePasteAsPlainText

Reported by: wmnieri Owned by: martinkou
Priority: Normal Milestone: FCKeditor 2.5 Beta
Component: General Version: FCKeditor 2.3.2
Keywords: Confirmed SF Cc: stephantual_@…

Description

ForcePasteAsPlainText is set to true.

On drag & drop I get this HTML: <p class="huvudmall" style="MARGIN: 0cm -8.5pt 0pt 0cm; tab-stops: 65.2pt"><span lang="EN-GB" style="COLOR: red"><font size="3"><font face="Times New Roman">link<o:p></o:p></font></font></span></p>

On paste I get this HTML: <p>link</p>

Change History

  Changed 18 months ago by alfonsoml

  • cc stephantual_@… added
  • keywords Confirmed SF added
  • milestone deleted

Drag drop should be treated same as copy/paste

If you copy paste something in FCKeditor on ie6.0/Winxpsp2, the 'onPaste' event is fired as normal.

However if you drag and drop content in the editor pane the onPaste event isn't fired. This a problem for the 'auto detect paste from word' feature, which doesn't work if the text was drag/dropped rather than copy/pasted.

Moved from SourceForge. Original poster: Stephan Tual
https://sourceforge.net/support/tracker.php?aid=1513029

  Changed 18 months ago by alfonsoml

#423 has been marked as dup

  Changed 18 months ago by fredck

  • summary changed from Drag & drop do not clean word formatting to Drag & drop do not honor ForcePasteAsPlainText
  • milestone set to FCKeditor 2.5

Still to check what can be done here.

I believe we can handle it in IE with the exact same results as with pasting.

With Firefox I think we may find problems. I think we can block drops, but not manipulate their data.

Well... still to analyze and check.

  Changed 15 months ago by martinkou

For IE, it should be possible with the ondrop event and the dataTransfer object. The mechanism is quite well documented in the MSDN article About DHTML Data Transfer.

For Gecko based browsers, it is possible to capture and block drop events. But getting the data inside the dropped object would require privileged access and signed scripts. So we can just block the drop event and display the "Paste As Text" dialog in Firefox. A simple drop blocker can be found below: 

<html>
	<head>
		<title>Firefox dragdrop blocker</title>
		<script type="text/javascript">
function dragDropListener( evt )
{
	alert( "Drop Event Captured!" ) ;
	evt.preventDefault() ;
	evt.stopPropagation() ;
}

function init()
{
	window.captureEvents( Event.DRAGDROP ) ;
	window.addEventListener( "dragdrop", dragDropListener, true ) ;
}
		</script>
	</head>
	<body onload="init();">
		Drop something on me.
	</body>
</html>

I'm not certain on how similar things can be done in Opera and Safari, yet.

  Changed 15 months ago by alfonsoml

One thing that I have thought might be possible to override all the restrictions to access the clipboard in IE7 as well as the rest as the browsers and also could be applied to this case is to use the Undo snapshot to compare the current content with the content that was present before the action, the difference between the two contents is what has been pasted or dropped on the editor, so we get it, do an undo to get to the previous state and then insert the cleaned new content.

If that would work it would mean that we could get rid of all the forced paste dialogs and the cleaning could be done automatically (just ask a confirmation at most)

about this bug: Opera doesn't implement drag&drop: #368

  Changed 15 months ago by martinkou

Ignoring our own processing logic like the EnterMode stuff, the browser would still process the pasted text depending on situation (e.g. substituting line breaks with <br> tags). If we were to implement paste features by comparing changes in HTML code, we'll need to figure out exactly how different browsers have changed the pasted stuff first. I don't know if that is feasible or not.

For now, I think I'll take the safe way to solve this bug. It should be possible to fix this for IE, Gecko and Safari. Opera ignores dropped data so lets just ignore that.

  Changed 15 months ago by martinkou

  • owner set to martinkou
  • status changed from new to assigned

  Changed 15 months ago by martinkou

Well... I can't get HTML data from event.dataTransfer in IE though. So auto detect paste from Word wouldn't work if I only use ondrop and dataTransfer on IE. :(

Looks like I should try Alfonso's method then.

  Changed 15 months ago by alfonsoml

My comment wasn't specifically target to this bug, but as a general method to get rid of problems accessing the clipboard.

I don't think that it will be too easy, but if we manage to make it work then it could mean that the editor will be much more user friendly, it will work just as they expect and they won't have to answer strange questions or remember to do things in some special way.

With the current Undo work that you have done I think that we might be able to achieve it, first for some specific situations and latter on we can keep on improving it.

  Changed 15 months ago by martinkou

  • status changed from assigned to closed
  • resolution set to fixed

I've committed [589] for fixing this bug.

[589] uses the more conservative approach ( i.e. block the drop request and display the paste or paste as plain text dialog if anything doesn't feel good ), since it is the easiest and the least error prone for a short term fix. The fix has been tested to work in IE, Gecko and Safari.

Alfonso's approach would be wonderful if it is made to work. However, it seems risky to me to implement that as a short term fix. Since I don't really know what are the potential pitfalls ( e.g. browser applied some transformations to the dropped stuff? ) to the approach.

  Changed 14 months ago by jonhg

  • status changed from closed to reopened
  • resolution deleted

This solution does not work very well when using drag and drop inside the editor.

I understand you want to filter the content when the user drags it from outside the editor, but it is very annoying that the paste popup comes when I try to move i.e a table in my text.

  Changed 14 months ago by martinkou

  • status changed from reopened to closed
  • resolution set to fixed

Thanks for the report. Actually I saw that happened today as well.

[602] fixes the issue where drag and drop actions within the editing area would invoke the paste dialogs. So now only dropped objects from outside of the editing area would cause dialog pop ups or paste-like actions.

  Changed 14 months ago by jonhg

  • status changed from closed to reopened
  • resolution deleted

Thanks for the solution!

To make this fix make work in IE7 I had to disable the overriding of the ondragover and ondragenter events. Then I can properly move my tables again.

It would have been nice if I could have invoked the documentProcessor after the ondrop event has finished. This way I could have been sure that the format is still legal (it is not wise to trust on IE) :) This method could also been used to filter incoming html code to correct format?

  Changed 14 months ago by martinkou

[606] fixes the issue where editor area contents cannot be moved around by drag and drop in Internet Explorer.

For the document processor issue, if you mean dropped objects from outside of the editor, then the added HTML is already processed. If you mean dragging and dropping objects within the editor area (e.g. moving tables in the editor), then there's no processing done yet.

follow-up: ↓ 17   Changed 14 months ago by jonhg

I added the document processor to the ondragend event and that seems to work when working inside the editor. This way I can prevent nested tables etc if I want this. But this event is not fired when the content comes from outside the editor.

I would really like another solution when dropping content from outside the editor because my customers do not like the paste popup and I have to remove it. But I has not been able to i.e run the word filter to the incoming html before adding it to page. Sometimes IE just make things so difficult.

  Changed 14 months ago by fredck

I'm having troubles with IE here.

To (try) to reproduce, load sample01.html in IE and open some site with Firefox. Then, drag some text from FF to IE. It should work the first time.

The, click on the toolbar background in the editor in IE. Go straight to FF and try to drag text again inside the editing area. A JavaScript error will be thrown, and the dragged text will end up in the toolbar.

I believe it is enough to force the focus in the editing area before pasting.

in reply to: ↑ 15   Changed 14 months ago by fredck

Replying to jonhg:

I would really like another solution when dropping content from outside the editor because my customers do not like the paste popup and I have to remove it. But I has not been able to i.e run the word filter to the incoming html before adding it to page. Sometimes IE just make things so difficult.

In IE we don't have the popup right now, and that is the best solution. So we are ok here.

In Firefox, there is no way to retrieve the data when dropping. So we have two options here: block the drop or display a dialog where the text can be dragged into again.

I particularly don't like the dialog solution in all situations. So, I believe we could have a dedicated configuration option for it, named "ShowDropDialog" (boolean).

That's all we can do for now on this for now, so this ticket can be closed. Enhancements on it should be requested with a new dedicated ticket.

  Changed 14 months ago by martinkou

  • status changed from reopened to closed
  • resolution set to fixed

After some experiments, I found the Doc_CancelDragDefault() function in fck_ie.js to be the culprit to the dropped contents being pasted outside of the editor. I thought that function is needed when I saw the MSDN example doing it, but for us it's causing problems.

I've also added the FCKConfig.ShowDropDialog option.

The changes are uploaded to [612] in our SVN system.

Note: See TracTickets for help on using tickets.