Bug Report T296118
Visible to All Users

ASPxHtmlEditor - Text is not pasted from Word in Merged formatting mode

created 9 years ago

[DevExpress Support Team: CLONED FROM T293094: ASPxHtmlEditor - List items (li) disappear from content pasted from Word in Merged formatting mode after switching to HTML view and back to Design]
The fix has resolved the original problem - li elements no longer disappear when switching between views for me. However, now, with the hotfix applied, the same inserted content from the same Word document gets deleted along with the empty paragraph I'm trying to put it into. I've attached a video demonstrating what happens. This seems to be specific to the Merge paste mode and does not happen with other modes. Also, I have not seen this before, so I think this is caused by the changes you've made to the pasting algorithm in the patch. Unfortunately, I have not been unable to create a standalone sample for this prolem yet - this seems to be specific to my app. Note that I have commented out my ASPxHtmlEditor customizations from my https://www.devexpress.com/Support/Center/Question/Details/T263833 and https://www.devexpress.com/Support/Center/Question/Details/T263850 cases when reproducing this, so this should not be related to them. The only use case when I managed to paste the content from Word in the Merged mode successfully is when the editor was totally empty (and no tags displayed in the Tag Inspector panel). Maybe you'll be able to figure out what code changes may cause this, or at least tell me where to look?
Also, I've noticed that the generated markup is very redundant and hard to maintain (not sure whether it was like that before). Here is what it looks like when I paste the sample Word document to an empty HTML file which has a style applied to its body:
Here's the body style:

CSS
body { font-family: "Helvetica Neue", "Lucida Grande", "Segoe UI", Arial, Helvetica, Verdana, sans-serif; margin: 0px; padding: 8px; color: #696969; text-align: justify; }

Here's the markup I get:

HTML
<p style="margin: 18pt 0cm 2pt; color: #000000; font-size: 14.6667px; font-family: Calibri, sans-serif;"> <span style="font-family: 'Helvetica Neue', 'Lucida Grande', 'Segoe UI', Arial, Helvetica, Verdana, sans-serif;"> <span style="font-size: 16px;"> <b> <span style="line-height: 107%; color: #0079c2;"> Test </span> </b> </span> </span> </p> <p style="color: #000000; font-size: 14.6667px; font-family: Calibri, sans-serif; margin: 0px 0px 10.6667px;"> <span style="font-family: 'Helvetica Neue', 'Lucida Grande', 'Segoe UI', Arial, Helvetica, Verdana, sans-serif;"> <span style="font-size: 16px;"> Test: </span> </span> </p> <ul style="margin: 0px; color: #000000; font-family: 'Times New Roman';" type="disc"> <li> <span style="font-family: 'Helvetica Neue', 'Lucida Grande', 'Segoe UI', Arial, Helvetica, Verdana, sans-serif;"> <span style="font-size: 16px;"> <b> Test </b> - <i> test </i> . </span> </span> </li> <li> <span style="font-family: 'Helvetica Neue', 'Lucida Grande', 'Segoe UI', Arial, Helvetica, Verdana, sans-serif;"> <span style="font-size: 16px;"> <b> Test </b> - <u> test </u> . </span> </span> </li> </ul> <p style="color: #000000; font-size: 14.6667px; font-family: Calibri, sans-serif; margin: 0px 0px 10.6667px;"> <span style="font-family: 'Helvetica Neue', 'Lucida Grande', 'Segoe UI', Arial, Helvetica, Verdana, sans-serif;"> <span style="font-size: 16px;"> Test. </span> </span> </p>

Here is the markup I would expect for the first paragraph:

HTML
<p style="margin: 18pt 0cm 2pt; font-size: 16px; line-height: 107%; color: #0079c2;"> <b> Test </b> </p>

The recommended changes are:

  1. No duplicated font-family overloads - why keep the Word font-family and then override it with the body font-family, if you can just remove the font-family at all - the result will be the same?
  2. No spans embedded into the <p> and <b> tags. Why do that if you can apply merged styles to the <p>, <li> and <b> tags directly?
  3. No duplicated overloads for font-size and color (again, why double-overload it?). And maybe no font-size at all if it's the default font-size of the Word document.
  4. Maybe no margins or line-height if it's the default values defined for the entire Word document.
    The same can be applied to ul / li and other tags. And an additional item for ul:
  5. I would not expect it to have the color: #000000 rule. This is the default color defined for the Word document and it should not persist, the body color should be used instead. I think you know how to figure out which styles are default for Word docs, because your Rich Edit Document Server knows how to do that. Not sure whether this can be applied to clipboard data, though. Even if's not applicable to clipboard, you can still figure out the data comes form Word (based on Word-specific stuff in the Word-generated HTML) and just hard-code the Word default values (the margins, the font color, font families, etc.) in your paste processing logic.
    I realize this is probably the expected behavior and yes, I know I can use the client-side event to adjust the pasted content myself (that's not going to be easy, though), but don't you think ASPxHtmlEditor will benefit from generating cleaner markup out-of-box? Yesterday, I sent a lengthy document via email to Vladimir from DX support team. Please show this comment to him and tell him it's a good example of what I was talking about in regards to pasted content in ASPxHtmlEditor. This redundant markup will become a nightmare if you decide to change the styles in a centralized manner after some editing.
    Also, please let him know this case is another example of a hotfix which breaks something which was not broken before.

Yes, and I'm still on Chrome 45, if that matters.
Nickolay, Software Architect
ClickHelp - Online Documentation Tool
http://clickhelp.co

Show previous comments (2)
CT CT
ClickHelp Team 9 years ago

    Oh, and by the way I'm on Word 2010 and the content removal issue does not happen for me as well if I paste to a totally empty document (I mean, it's just <body> and nothing else, the tag inspector is empty). That's the only use case when the content is pasted fine, in fact. If I have at least a single empty <p> as an insertion point, the pasted content is removed like you see in the screencast.
    Nickolay, Software Architect
    ClickHelp - Online Documentation Tool
    http://clickhelp.co

    CT CT
    ClickHelp Team 9 years ago

      OK, it took me three hours, but I think I reproduced it. Here is the sample project, the DOCX file and a Jing video just in case (the steps are the same, though: make two paragraphs of text, then paste the Word content into an empty paragraph between them).
      Nickolay, Software Architect
      ClickHelp - Online Documentation Tool
      http://clickhelp.co

      Nastya (DevExpress Support) 9 years ago

        Hello Nickolay,
        Thank you for the prepared project. I've managed to reproduce the same behavior in version 15.1.7.0. I forwarded this ticket to our developers for further research. Please bear with us. We will contact you as soon as we have any results.

        Answers approved by DevExpress Support

        created 9 years ago (modified 9 years ago)

        We have fixed the issue described in this ticket and will include the fix in our next maintenance update. To apply this solution before the official update, request a hotfix by clicking the corresponding link for product versions you require.

        Note: Hotfixes may be unavailable for beta versions and updates that are about to be released.

          Comments (1)
          CT CT
          ClickHelp Team 9 years ago

            Looks like this has been resolved - at least, I did not manage to break it so far.
            Nickolay, Software Architect
            ClickHelp - Online Documentation Tool
            http://clickhelp.co

            Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

            Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.