TypeError when parsing <constructor> element
#3709
Comments
daniellockyer
added a commit
to TryGhost/Ghost
that referenced
this issue
May 7, 2024
fix https://linear.app/tryghost/issue/SLO-87/cannot-read-properties-of-undefined-reading-createimpl-an-unexpected refs jsdom/jsdom#3709 - in the event we are given some HTML to parse, and that fails, we currently return a HTTP 500 because it's unhandled - the instance we saw was due to `<constructor>` crashing jsdom, we've opened an issue for that - in terms of handling the error gracefully, we can surround the code in a try-catch and return a more suitable error. I've gone for a ValidationError for now - you could debate whether a different one is more appropriate - also added Sentry error capturing so we're not blind to these, ultimately we should make sure the parser can handle all user-submitted data
daniellockyer
added a commit
to TryGhost/Ghost
that referenced
this issue
May 7, 2024
fix https://linear.app/tryghost/issue/SLO-87/cannot-read-properties-of-undefined-reading-createimpl-an-unexpected refs jsdom/jsdom#3709 - in the event we are given some HTML to parse, and that fails, we currently return a HTTP 500 because it's unhandled - the instance we saw was due to `<constructor>` crashing jsdom, we've opened an issue for that - in terms of handling the error gracefully, we can surround the code in a try-catch and return a more suitable error. I've gone for a ValidationError for now - you could debate whether a different one is more appropriate - also added Sentry error capturing so we're not blind to these, ultimately we should make sure the parser can handle all user-submitted data
daniellockyer
added a commit
to TryGhost/Ghost
that referenced
this issue
May 7, 2024
fix https://linear.app/tryghost/issue/SLO-87/cannot-read-properties-of-undefined-reading-createimpl-an-unexpected refs jsdom/jsdom#3709 - in the event we are given some HTML to parse, and that fails, we currently return a HTTP 500 because it's unhandled - the instance we saw was due to `<constructor>` crashing jsdom, we've opened an issue for that - in terms of handling the error gracefully, we can surround the code in a try-catch and return a more suitable error. I've gone for a ValidationError for now - you could debate whether a different one is more appropriate - also added Sentry error capturing so we're not blind to these, ultimately we should make sure the parser can handle all user-submitted data
daniellockyer
added a commit
to TryGhost/Ghost
that referenced
this issue
May 7, 2024
fix https://linear.app/tryghost/issue/SLO-87/cannot-read-properties-of-undefined-reading-createimpl-an-unexpected refs jsdom/jsdom#3709 - in the event we are given some HTML to parse, and that fails, we currently return a HTTP 500 because it's unhandled - the instance we saw was due to `<constructor>` crashing jsdom, we've opened an issue for that - in terms of handling the error gracefully, we can surround the code in a try-catch and return a more suitable error. I've gone for a ValidationError for now - you could debate whether a different one is more appropriate - also added Sentry error capturing so we're not blind to these, ultimately we should make sure the parser can handle all user-submitted data
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Basic info:
General
We use jsdom within Ghost and noticed that some inputs are erroring out within jsdom. After investigation, it seems to be due to the use of
<constructor>within the body.Minimal reproduction case
I get this stack trace:
Whereas using an element of a different name,
<abc>, works.How does similar code behave in browsers?
I would expect the code not to crash on this element 🙂
The text was updated successfully, but these errors were encountered: