HTML API: Ignore leading newline after seeking to text following PRE - #60
Open
sirreal wants to merge 3 commits into
Open
HTML API: Ignore leading newline after seeking to text following PRE#60sirreal wants to merge 3 commits into
sirreal wants to merge 3 commits into
Conversation
The first newline after LISTING and PRE opening tags is ignored as an authoring convenience. The Tag Processor tracks where such a newline would be found and ignores it when reading modifiable text, but this single tracked offset is overwritten upon scanning past any later LISTING or PRE opening tag. Seeking directly to a bookmarked text node restored the cursor without restoring that state, so the same token could report different modifiable text on a repeat visit: $processor = new WP_HTML_Tag_Processor( "<pre>\nX<pre>" ); $processor->next_token(); // PRE. $processor->next_token(); // #text. $processor->get_modifiable_text(); // 'X' $processor->set_bookmark( 'text' ); $processor->next_token(); // Second PRE clobbers state. $processor->seek( 'text' ); $processor->get_modifiable_text(); // "\nX" - wrong! Resolve this by recording, for each bookmark, whether its token immediately follows a LISTING or PRE opening tag, and restoring the ignored-newline state from the bookmark when seeking. Because the recorded state is keyed to the bookmark, it shifts together with the bookmark when applied document updates move token offsets. This also prevents a stale tracked offset from colliding with an unrelated token's post-update location, which could previously strip a newline that should have been preserved. Removes the corresponding documented limitation on get_modifiable_text() and the skipped-test guard which covered it. See #65372.
The position where an ignorable newline may follow a LISTING or PRE opening tag was never adjusted when applying enqueued updates, even though those updates shift the offsets of everything after them in the document. Applying updates while paused on the text node following one of these tags changed what get_modifiable_text() returned: $processor = new WP_HTML_Tag_Processor( "<pre class=\"x\">\nfoo" ); $processor->next_token(); // PRE. $processor->remove_attribute( 'class' ); $processor->next_token(); // #text. $processor->get_modifiable_text(); // 'foo' $processor->get_updated_html(); $processor->get_modifiable_text(); // "\nfoo" - wrong! A stale position also poisoned the ignored-newline state recorded for bookmarks set after applying updates, which could reintroduce the inconsistency through seek(). Resolve this by accumulating, against the original document coordinates, the shift from every update located before the ignored- newline position, and applying the sum once after the updates are written - the same pattern used for shifting a given pointer. Comparing against original coordinates matters: adjusting the position inside the update loop would compare earlier-shifted values against later updates' unshifted offsets and apply the wrong total shift when multiple updates are applied together. Follow-up to [63ac0ac]. See #65372.
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
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
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
PREorLISTING.skip_newline_atwhen queued updates move the affected text token.TEXTAREA, and opener-seek behavior unchanged.Testing
codex review --base trunk.Trac ticket: https://core.trac.wordpress.org/ticket/65372
Use of AI Tools
AI assistance: Yes
Tool(s): Codex
Model(s): GPT-5.5
Used for: PR description cleanup and code review.
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.