ShowDropDialog must be considered only when ForcePasteAsPlainText = true

[fredck]

For #338, we have introduced a new feature which guarantees that dropped text will respect the ForcePasteAsPlainText setting, not allowing dropping rich contents in that case.

The solution used is trying to transform the dropped data to simple text on the fly (IE only), showing a dialog to which dropping is possible, or even disable dropping all the way. To disable it, the ShowDropDialog can be set to "false".

But, the current implementation makes it impossible to have the normal dropping behavior because the editor always looks for the ShowDropDialog, even if ForcePasteAsPlainText = false. It should not happen instead.

[fredck]

Probably this is related to a misinterpretation of my comments in #338, like:

"we have two options here: block the drop or display a dialog where the text can be dragged into again"

My fault. As that ticket is related to ForcePasteAsPlainText, I thought it was clear that I was talking about it. I'll try to be clearer from now on.

[fredck]

Patch for trunk r1232

[alfonsoml]

Wouldn't it be better if the gecko code followed the same logic than the IE and instead of using return it cancels the event only if ForcePasteAsPlainText is enabled?

	if ( FCKConfig.ForcePasteAsPlainText )
	{
		if ( evt.dataTransfer )
		{
			var text = evt.dataTransfer.getData( 'Text' ) ;
			text = FCKTools.HTMLEncode( text ) ;
			text = FCKTools.ProcessLineBreaks( window, FCKConfig, text ) ;
			FCK.InsertHtml( text ) ;
		}
		else if ( FCKConfig.ShowDropDialog )
			FCK.PasteAsPlainText() ;

		evt.preventDefault() ;
		evt.stopPropagation() ;
	}
}

[fredck]

You comment is correct Alfonso. Feel free to mark "Review-" in those cases. If I think I did it well, I'll explain it and call "Review?" again.

That "else return" call was useless. There was also a small fix for IE (moving the evt declaration inside the if).

The new patch fixes both things.

[fredck]

Fixed with [1449]. Click here for more info about our SVN system.