-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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 Processor: Fix a problem backing up too far after updating HTML #46597
Closed
Conversation
This file contains 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
…alBlockInspectorAnimation
Co-authored-by: Ben Dwyer <ben@escruffian.com>
Co-authored-by: Glen Davies <glen.davies@automattic.com>
* Migrate qupte e2e tests to playwright * Use inline snapshots * Add `deleteAllPosts` * Use accesible selector * Add an inline comment for `pressKeyTimes`
A defect introduced in #46018 led to the tag processor backing up one index too far after flushing its queued changes on a document. For most operations this didn't cause any harm because when immediately moving forward after an update, the `next_tag()` returned to the same spot: it was backing up to one position before the current tag instead of at the start of the current tag. Unfortunately, when the current tag was the first in the document this would lead the processor to rewind to position `-1`, right before the start of the document, and lead to errors with `strpos()` when it received out-of-bounds indices. In this fix we're correcting the adjustment for the HTML tag's `<` and documenting the math in the file so that it's clearer why it's there and providing guidance should another fix be necessary. Props to @anton-vlasenko for finding this bug.
dmsnell
force-pushed
the
fix/tag-processor-back-too-far
branch
from
December 15, 2022 23:36
133b0d2
to
bdea1f3
Compare
dmsnell
requested review from
TimothyBJacobs,
geriux,
noahtallen,
ellatrix,
fluiddot,
ajitbohra,
ntwb,
nerrad,
noisysocks,
tellthemachines,
ryanwelcher,
juanmaguitar and
fabiankaegy
as code owners
December 15, 2022 23:36
dmsnell
changed the base branch from
trunk
to
fix/parity-with-cores-php-ci-jobs
December 15, 2022 23:37
dmsnell
changed the base branch from
fix/parity-with-cores-php-ci-jobs
to
trunk
December 15, 2022 23:37
Blarg |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What
Fixes a bug in the HTML Tag Processor when updating a document when the internal pointer is at the first tag in the document.
Why?
The Tag Processor shouldn't break code relying on it.
How?
A defect introduced in #46018 led to the tag processor backing up one index too far after flushing its queued changes on a document.
For most operations this didn't cause any harm because when immediately moving forward after an update, the
next_tag()
returned to the same spot: it was backing up to one position before the current tag instead of at the start of the current tag.Unfortunately, when the current tag was the first in the document this would lead the processor to rewind to position
-1
, right before the start of the document, and lead to errors withstrpos()
when it received out-of-bounds indices.In this fix we're correcting the adjustment for the HTML tag's
<
and documenting the math in the file so that it's clearer why it's there and providing guidance should another fix be necessary.Props to @anton-vlasenko for finding this bug.
Testing Instructions
Run the PHP unit test suite with PHP <= 7.0.
Tests should start failing in
trunk
but should pass in this branch.Temporarily rebasing against
fix/parity-with-cores-php-ci-jobs
in this PR to run such tests in CI.