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

Tag is ignored when double quote is missing in tag attribute #114

Open
StarpTech opened this issue Jul 3, 2022 · 4 comments
Open

Tag is ignored when double quote is missing in tag attribute #114

StarpTech opened this issue Jul 3, 2022 · 4 comments
Assignees
Labels
bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed

Comments

@StarpTech
Copy link

StarpTech commented Jul 3, 2022

What happened?

This was quite hard to debug. I had the following:

{% quote content="test /%}

No error was thrown. I'd expect that the parser throws an error.

To reproduce

See above.

Version

0.1.3

Additional context

No response

@StarpTech StarpTech added the bug Something isn't working label Jul 3, 2022
@mfix-stripe mfix-stripe added good first issue Good for newcomers help wanted Extra attention is needed labels Aug 1, 2022
@rpaul-stripe
Copy link
Contributor

(Originally posted this on #160, reproducing here for completeness)

The underlying problem here is with the way that Markdoc identifies the end of a tag construct in content. When it sees a {% in the text, it scans forward each character until it finds a matching %} that is not inside of a string. It does this in order to avoid prematurely identifying the tag end when it encounters tag-like syntax inside of a string attribute value. This means that if a tag has an unterminated string, the parser assumes that the actual closing is still inside of that string and it declines to match it as a tag.

What we should probably do is solve this in the markdown-it plugin and make the parser generate an error for the whole block any time it sees the tag start syntax without a matched end. I think this would be cleaner than trying to identify malformed tags during the validation process. I will tackle fixing this myself at some point in the next week or two.

For now, if you want to be able to catch these cases reliably during validation without a large surface area of potential false positives, I would suggest overriding the text schema node and doing the validation check there. Here's a quick-and-dirty example of something you can include in your Markdoc config to achieve this:

export const text: Schema = {
  attributes: {
    content: { type: String, required: true },
  },
  transform(node) {
    return node.attributes.content;
  },
  validate(node: Node, config: Config) {
    if (node.attributes?.content?.match?.(/{%[^%}]+%}/)) {
      return [{
        id: 'attribute-value-invalid',
        level: 'error',
        message:
          'The string attribute must have an opening and closing quote',
      }]

    return [];
  }

Thanks for raising this issue!

@urica12
Copy link

urica12 commented Nov 29, 2022

What happened?

This was quite hard to debug. I had the following:

{% quote content="test /%}

No error was thrown. I'd expect that the parser throws an error.

To reproduce

See above.

Version

0.1.3

Additional context

No response

Test

@urica12
Copy link

urica12 commented Nov 29, 2022

What happened?

This was quite hard to debug. I had the following:

{% quote content="test /%}

No error was thrown. I'd expect that the parser throws an error.

To reproduce

See above.

Version

0.1.3

Additional context

No response

Test

Test

@urica12
Copy link

urica12 commented Nov 29, 2022

What happened?

This was quite hard to debug. I had the following:

{% quote content="test /%}

No error was thrown. I'd expect that the parser throws an error.

To reproduce

See above.

Version

0.1.3

Additional context

No response

Test

Test

{% quote content="test /%}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants