Skip to content
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

Open
4 of 6 tasks
mohd-akram opened this issue Aug 30, 2023 · 1 comment
Open
4 of 6 tasks

unpairedTags option does not work correctly with text nodes #609

mohd-akram opened this issue Aug 30, 2023 · 1 comment
Labels
Pending Pending to be confirmed by user/author for some check/update/implementation

Comments

@mohd-akram
Copy link

  • Are you running the latest version?
  • Have you included sample input, output, error, and expected output?
  • Have you checked if you are using correct configuration?
  • Did you try online tool?

Description

The unpairedTags option does not seem to behave correctly with text nodes.

Input

Code

const assert = require('assert/strict');

const { XMLParser, XMLBuilder } = require('fast-xml-parser');

const html = '<div>1<br>2<br></div>';
console.log(html);

const parsingOptions = {
  preserveOrder: true,
  unpairedTags: ['br'],
};
const parser = new XMLParser(parsingOptions);
const result = parser.parse(html);
console.log(JSON.stringify(result, null, 2));

const builderOptions = {
  preserveOrder: true,
  unpairedTags: ['br'],
}
const builder = new XMLBuilder(builderOptions);
const output = builder.build(result);
console.log(output);

assert.equal(output, html);

Output

[
  {
    "div": [
      {
        "#text": 1
      },
      {
        "br": [
          {
            "#text": 2
          }
        ]
      },
      {
        "br": []
      }
    ]
  }
]
<div>1<br><br></div>

expected data

[
  {
    "div": [
      {
        "#text": 1
      },
      {
        "br": []
      },
      {
        "#text": 2
      },
      {
        "br": []
      }
    ]
  }
]
<div>1<br>2<br></div>

Would you like to work on this issue?

  • Yes
  • No

Bookmark this repository for further updates. Visit SoloThought to know about recent features.

@github-actions
Copy link

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 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
Labels
Pending Pending to be confirmed by user/author for some check/update/implementation
Projects
None yet
Development

No branches or pull requests

2 participants