-
Notifications
You must be signed in to change notification settings - Fork 3.1k
HTML API: Reduce skip_script_data length checks #9230
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
Closed
sirreal
wants to merge
13
commits into
WordPress:trunk
from
sirreal:html-api/improve-skip-script-data-len-checks
Closed
Changes from 12 commits
Commits
Show all changes
13 commits
Select commit
Hold shift + click to select a range
6ad9951
Move script data length checks to top of loop
sirreal b3b3177
Remove parser_state change in skip_script_data
sirreal ca16e0e
Remove more length checks
sirreal 0456be7
Improve documentation
sirreal ea6f7d3
Improve comment explaining early return logic
sirreal 4be62b9
Improve loop comment
sirreal df2affa
Add script tag processing tests
sirreal d0cbb00
Remove problematic tests
sirreal aaa6763
Reword explanatory comment.
dmsnell f7d4b8e
Move script parsing adjacent to other script parsing test
sirreal c3c76d6
Merge branch 'trunk' into html-api/improve-skip-script-data-len-checks
sirreal 34c3b28
Continue to tweak comment and improve examples
sirreal 325bcb8
Merge branch 'trunk' into html-api/improve-skip-script-data-len-checks
sirreal File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this patch is good, but before we merge, can we also note in this comment that we’re looking for other strings and they are covered here? I think the comment at the moment is slightly misleading, but we also check for
<!--
for instance, and it’s currently incidental I think that terminatingfalse
is the same for all places within the SCRIPT.imagine, however, that we wanted to signal something different if we failed to exit the SCRIPT because there was no end-tag vs. that we ended inside some escaped state? then, by returning early at this point we removed our ability to find the
<!--
that transitions state.I believe in review that the code is solid, but I want to make sure we leave this note for the future as a warning to reconsider the check if changing things. I don’t know that these are all currently caught in the tests (which of course would be another great way to cover this risk, by adding new tests for each of these cases, if we can properly think them up).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, I've updated the comment to clarify things.
I do have a number of tests to add to this. I can push them to this branch.
Given how complicated script tag parsing is, I'm tempted to extract them to their own test suite like
wpHtmlTagProcessor-scriptParsing
. Do you have thoughts on that?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pulled in your comment changes from #9397 and made some further tweaks. I'm pretty happy with it now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
your third example in the comment is perfect. I was probably lazy in not suggesting that in my comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not that I consider it a huge priority, but I think this is a great idea and would make it clearer for us to be more comprehensive in the tests. I think for every branch of the state machine in the HTML spec we could have data providers generating example inputs for them.