-
-
Notifications
You must be signed in to change notification settings - Fork 310
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unpairedTags
option does not work correctly with text nodes
#609
Labels
Pending
Pending to be confirmed by user/author for some check/update/implementation
Comments
We're glad you find this project helpful. We'll try to address this issue ASAP. You can vist https://solothought.com to know recent features. Don't forget to star this repo. |
mohd-akram
added a commit
to open-craft/frontend-lib-content-components
that referenced
this issue
Sep 4, 2023
The issue had to do with how Firefox handles pasting newlines inside a <pre contenteditable> tag (TinyMCE's editor works via contenteditable) and fast-xml-parser's parsing. In Firefox, newlines are converted to <br> when pasted, while Chrome preserves them. The parser by default trims spaces in text nodes. In Firefox, the parser creates individual text nodes between the <br> elements, and those have leading spaces in the example. In Chrome, there are no <br> elements and the entire content is a single text node as-is. Setting trimValues to false disables the trimming and resolves this issue in Firefox. While investigating this, I noticed the builder also mishandles <br /> tags emitted by the editor, converting them to <br></br>. The unpairedTags option in the builder ensures they are output correctly as a single tag, and setting suppressUnpairedNode to false ensures that single tag is <br/> rather than <br> to remain XML compatible. While trying to resolve this, I was looking into the paste plugin in TinyMCE. It changes the behavior of pasting, making it more consistent between Chrome and Firefox (i.e. both emit <br>) and is incorporated into TinyMCE 6 core. Unfortunately, it seems to mangle pasting inside a <pre> tag by inserting redundant nbsp characters (tinymce/tinymce#9017). TinyMCE 6 also outputs <br> rather than <br /> - adding unpairedTags to the parser options is meant to handle this, but it does not seem to behave entirely correct (NaturalIntelligence/fast-xml-parser#609). These should be kept in mind if/when upgrading to TinyMCE 6 (the different behaviors can be seen easily at https://fiddle.tiny.cloud).
amitguptagwl
added
the
Pending
Pending to be confirmed by user/author for some check/update/implementation
label
Sep 10, 2023
brian-smith-tcril
pushed a commit
to openedx/frontend-lib-content-components
that referenced
this issue
Sep 11, 2023
The issue had to do with how Firefox handles pasting newlines inside a <pre contenteditable> tag (TinyMCE's editor works via contenteditable) and fast-xml-parser's parsing. In Firefox, newlines are converted to <br> when pasted, while Chrome preserves them. The parser by default trims spaces in text nodes. In Firefox, the parser creates individual text nodes between the <br> elements, and those have leading spaces in the example. In Chrome, there are no <br> elements and the entire content is a single text node as-is. Setting trimValues to false disables the trimming and resolves this issue in Firefox. While investigating this, I noticed the builder also mishandles <br /> tags emitted by the editor, converting them to <br></br>. The unpairedTags option in the builder ensures they are output correctly as a single tag, and setting suppressUnpairedNode to false ensures that single tag is <br/> rather than <br> to remain XML compatible. While trying to resolve this, I was looking into the paste plugin in TinyMCE. It changes the behavior of pasting, making it more consistent between Chrome and Firefox (i.e. both emit <br>) and is incorporated into TinyMCE 6 core. Unfortunately, it seems to mangle pasting inside a <pre> tag by inserting redundant nbsp characters (tinymce/tinymce#9017). TinyMCE 6 also outputs <br> rather than <br /> - adding unpairedTags to the parser options is meant to handle this, but it does not seem to behave entirely correct (NaturalIntelligence/fast-xml-parser#609). These should be kept in mind if/when upgrading to TinyMCE 6 (the different behaviors can be seen easily at https://fiddle.tiny.cloud).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
The
unpairedTags
option does not seem to behave correctly with text nodes.Input
Code
Output
expected data
Would you like to work on this issue?
Bookmark this repository for further updates. Visit SoloThought to know about recent features.
The text was updated successfully, but these errors were encountered: