[wp-trac] [WordPress Trac] #59607: HTML API: Fix - avoid calling subclass method while internally scanning in Tag Processor

WordPress Trac noreply at wordpress.org
Thu Oct 12 23:26:30 UTC 2023


#59607: HTML API: Fix - avoid calling subclass method while internally scanning in
Tag Processor
--------------------------+-----------------------------
 Reporter:  dmsnell       |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  HTML API      |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 After modifying tags in the HTML API, the Tag Processor backs up to before
 the tag being modified and then re-parses its attributes. This saves on
 the code-complexity involved in applying updates, which have already been
 transformed to "lexical updates" by the time they are applied.

 In order to do that, get_updated_html() calls next_tag() to reuse its
 logic. Unfortunately, as a public method, subclasses may change the
 behavior of that method, and the HTML Processor does just this. It
 maintains an HTML stack of open elements and when the Tag Processor calls
 this method to re-scan a tag and its attributes, it leads to a broken
 stack.

 To fix this, this patch replaces the call to next_tag() with a more
 appropriate reapplication of its internal parsing logic to rescan the tag
 name and its attributes. Given the limited nature of what's occurring in
 get_updated_html() this should bring with it certain guarantees that no
 HTML structure is being changed (that structure will only be changed by
 subclasses like the HTML Processor).

 This patch resolves an issue discovered by @adamziel during testing of the
 HTML Processor.

 ---

 No code in Gutenberg relies on the HTML Processor and no code has appeared
 in the WP Directory relying on it, so the probably extent of the impact of
 this defect is minimal at worst. It's possible that this bug has never
 been triggered on a real site.

 One could argue that this patch belongs in 6.4 because it fixes a bug in
 `get_breadcrumbs()` and `matches_breadcrumbs()`, but given the severity
 and expose I don't see a compelling argument to rush it into the release,
 if people don't want to add yet-another change.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59607>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list