Trix Editor 2.1.14 Extra Newlines When Pasting From Microsoft Editor
This article addresses an issue encountered in Trix editor version 2.1.14 where extra newlines are introduced when pasting text from Microsoft applications like Outlook and Word. This behavior differs from the previous version, 2.1.13, where the pasting functionality worked as expected. This article provides a detailed explanation of the problem, steps to reproduce it, and the underlying cause related to the DOMPurify upgrade.
Problem Description
In Trix 2.1.14, when text containing multiple lines is copied from Microsoft applications (e.g., Outlook, Word) and pasted into the Trix editor, extra newline characters are inserted, leading to incorrect formatting. This issue was not present in Trix 2.1.13.
To illustrate, consider the following text:
Line 1
Line 2
When pasted into Trix 2.1.13, the text appears correctly:
Line 1
Line 2
However, in Trix 2.1.14, the pasted text includes extra newlines:
Line 1
Line 2
This behavior disrupts the intended formatting and requires manual correction, affecting user experience and workflow efficiency.
Steps to Reproduce
To replicate this issue, follow these steps:
-
Compose an Email in Outlook: Begin by composing an email in Microsoft Outlook.
-
Enter Multi-line Text: Type two or more lines of text, such as:
Line 1 Line 2
-
Copy the Text: Select the text and copy it to the clipboard.
-
Paste into Trix Editor (v2.1.14): Paste the copied text into a Trix editor running version 2.1.14.
-
Observe the Extra Newlines: The pasted text will exhibit extra newlines between the lines.
For testing purposes, an HTML document can be used:
<html>
<head>
<link rel="stylesheet" href="https://unpkg.com/[email protected]/dist/trix.css">
<script src="https://unpkg.com/[email protected]/dist/trix.umd.js"></script>
</head>
<body>
<trix-editor></trix-editor>
</body>
</html>
Using this HTML setup, you can quickly test the behavior of Trix 2.1.14 with pasted content from Microsoft applications. It's important to ensure you are using version 2.1.14 to observe the issue. Testing with version 2.1.13 will confirm the absence of this problem, highlighting the regression introduced in the newer version.
Root Cause Analysis
The underlying cause of this issue is related to the DOMPurify upgrade within Trix 2.1.14. DOMPurify is a library used for sanitizing HTML to prevent cross-site scripting (XSS) vulnerabilities. The update in Trix 2.1.14 has altered the way HTML is processed, specifically affecting content pasted from Microsoft applications.
In Trix versions prior to 2.1.14, when text was pasted from Microsoft applications, the HTMLSanitizer.setHTML
function would receive HTML content that included <style>
elements containing CSS definitions. For example:
<div style="display: none;">
<p class="MsoNormal"><span style="mso-fareast-font-family:"Times New Roman";
color:black">Line 1</span></p>
<p class="MsoNormal"><span style="mso-fareast-font-family:"Times New Roman";
color:black">Line 2</span></p>
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;
mso-font-charset:0;
mso-generic-font-family:roman;
mso-font-pitch:variable;
mso-font-signature:-536870145 1107305727 0 0 415 0;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:536871559 3 0 0 415 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-parent:"";
margin:0in;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:"Aptos",sans-serif;
mso-fareast-font-family:Aptos;
mso-bidi-font-family:Aptos;}
.MsoChpDefault
{mso-style-type:export-only;
mso-default-props:yes;
font-size:10.0pt;
mso-ansi-font-size:10.0pt;
mso-bidi-font-size:10.0pt;
mso-font-kerning:0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.WordSection1
{page:WordSection1;}
-->
</style></div>
The <style>
element appears to play a crucial role in how newlines are interpreted. In Trix 2.1.14, the <style>
element is no longer present after the HTMLSanitizer.setHTML
function is called. This change in behavior introduced by the DOMPurify upgrade leads to the extra newlines being inserted.
Manually adding the <style>
element back into the HTML after HTMLSanitizer.setHTML
is called has been found to resolve the issue, suggesting that the presence of the <style>
block influences the correct rendering of newlines.
This detailed analysis points to a specific change in how Trix 2.1.14 handles HTML sanitization, particularly the removal of <style>
elements, as the root cause of the extra newline issue when pasting from Microsoft applications.
Workaround
While a permanent fix is being developed, a temporary workaround involves manually adding the <style>
element back into the HTML content after it has been sanitized by HTMLSanitizer.setHTML
. This can be achieved by intercepting the sanitized HTML and re-inserting the necessary style definitions.
Conclusion
The introduction of extra newlines when pasting from Microsoft applications in Trix 2.1.14 is a significant issue that impacts the editor's usability. This article has provided a comprehensive analysis of the problem, including steps to reproduce it and a detailed explanation of the root cause related to the DOMPurify upgrade. Understanding the cause allows for targeted solutions and workarounds, ensuring a smoother user experience while a permanent fix is implemented. The workaround, which involves manually adding the <style>
element back into the sanitized HTML, offers a temporary solution for those affected by this issue.