[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:
CSSbody {
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:
- 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?
- 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?
- 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.
- 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: - 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
Hello Nickolay,
I tried to reproduce the behavior illustrated in your screencast but did not succeed (please see the attached). I suppose your scenario contains different factors that affect the issue. In order to find its cause and provide you with a solution, I need to reproduce the behavior on our side. Would you please create a sample and send it to us for research?
P.S. Thank you for pointing out the issue. I have forwarded this information to Vladimir, and he is analyzing your document. He will contact you as soon as he gets any results.
I wish I could. I spend about half my time reproducing issues and creating samples for you these days, but still I'm unable to reproduce this one and the weird CSS classes removal / strange <div style> from https://www.devexpress.com/Support/Center/Question/Details/T295900 outside of my app.
Apparently, something got broken with Merge pasting in my app and I need a hint on what else to try / what can be affecting it. I was hoping that your devs would be able to figure out something if they compare the source changes between the hotfix and the release version. Even if this does not help them find the root cause, maybe this will give a clue on where to look? The editor in my sample application is already quite similar to my real editor in terms of customization, but still I'm out of luck reproducing the issue with the sample :(
Nickolay, Software Architect
ClickHelp - Online Documentation Tool
http://clickhelp.co
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
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
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.