Opened 11 years ago

Closed 11 years ago

Last modified 9 years ago

#8063 closed defect (fixed)

TextArea: pasting rich text doesn't get converted to plain text

Reported by: erikcw Owned by: Douglas Hays
Priority: high Milestone: 1.3
Component: Dijit - Form Version: 1.2.1
Keywords: dijit, form, textarea, rich text, formatting Cc: erik@…, Douglas Hays
Blocked By: Blocking:

Description

When formatted text (ie large, bold, red font) from MS Word (and OO Writer) is pasted into a dijit.form.Textarea the formatting is preserved.

When the form is submitted server side, the field is full of formatting garbage like this:

normal0microsoftinternetexplorer4st1\\:*{behavior:url(#ieooui) } /*
style definitions */ table.msonormaltable\t{mso-style-name:"table normal";\tmso-
tstyle-rowband-size:0;\tmso-tstyle-colband-size:0;\tmso-style-noshow:yes;\tmso-s
tyle-parent:"";\tmso-padding-alt:0in 5.4pt 0in 5.4pt;\tmso-para-margin:0in;\tmso
-para-margin-bottom:.0001pt;\tmso-pagination:widow-orphan;\tfont-size:10.0pt;\tf
ont-family:"times new roman";}my text here

If formatted text is desired in tho dijit Textbox, there should be an attribute to turn it off, strip formating, and leave plain text. This will allow dijit.form.Textbox to server as a drop in replacement for an html textarea.

Change History (6)

comment:1 Changed 11 years ago by bill

Cc: Douglas Hays added
Summary: Rich text formatting in dijit.form.TextareaTextArea: pasting rich text doesn't get converted to plain text

Doug, any ideas on this one?

It would be nice for the formatting to be erased on paste (or at least appear that way to the user). But, the only way I can think to do that, short of some fancy thng that is constantly monitoring the input and cleansing it (ie, converting to plain text), is to reimplement the widget using a <textarea> instead of a contentEditable <div> / <iframe>.

The original reason we didn't do that (IIRC) was that it required javascript sizing on instantiation, which was a performance problem and also might have issues if the TextArea is initially hidden. And also a problem w/some browser (FF2?) that you couldn't shrink the size of the <textarea> when the user deleted text.

As for the first problem I was wondering if we could initially display the widget using a plain <div>, but then convert it to a <textarea> on focus. Or perhaps the <textarea> is there all along, but hidden. I'm not sure how complicated that would be though w.r.t. remembering the old cursor position etc.

comment:2 Changed 11 years ago by bill

Milestone: tbd1.4

comment:3 Changed 11 years ago by bill

I spoke to Doug about this and #8065 yesterday:

  • pasting from word will show up as rich text since we are using a contentEditableDiv. See more on this below.
  • problem w/text being submitted: apparently pasting from word can insert a <style> tag with a bunch of CSS in it. The regex in dijit.Textarea to convert rich text to plain text isn't setup to handle anything so complex. It would probably need to do DOM traversal in order to drop the whole <style> node and it's textual content. (If we did continue to use a regular expression, would need to make sure that it didn't remove the real text in an example like:
    <style>...</style>
    real text
    <style>...</style>
    

Would really like to use a real <textarea> node rather than a contentEditable <div>. But with a <textarea> node the automatic height adjustment is tricky. The obvious approach is to calculate the height by scanning the text searching for newlines and line overflows (whenever there is continguous text for X characters w/out a newline), but that's probably unreliable, even when using a "fixed-size" font, given that the text could contain tabs or kanji characters of different width than the roman A-Z characters.

So, an alternative might be to have two <textarea> nodes, one that is displayed and another that is visibility:hidden, position:absolute, with a 1px height. If we synced the contents of the two <textareas> then we could set visibleTextarea.style.height = hiddenTextarea.scrollheight.

comment:4 Changed 11 years ago by bill

Milestone: 1.41.3
Owner: set to Douglas Hays

Should be solved by your in-progress refactor.

comment:5 Changed 11 years ago by Douglas Hays

Resolution: fixed
Status: newclosed

(In [16090]) Fixes #2178, #4988, #7383, #8063, #8211, #8222, #8274, #8276. References #7740. Refactor the Textarea widget to use a native TEXTAREA element. IE8 beta 2 in strict mode will not auto-resize.

comment:6 Changed 9 years ago by bill

Component: DijitDijit - Form
Note: See TracTickets for help on using tickets.