[wp-trac] [WordPress Trac] #63891: Processing directives function in interactivity API class may cause fatal error

[WordPress Trac]

#63891: Processing directives function in interactivity API class may cause fatal
error
--------------------------------------+--------------------------------
 Reporter:  hugosolar                 |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Interactivity API         |     Version:  6.5
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  php-compatibility
--------------------------------------+--------------------------------

Comment (by jonsurrell):

 To clarify, special `</br>` handling already exists in the Tag Processor,
 which is why this is exceptional. I believe it's the only case where you
 can do this:

 {{{#!php
 <?php
 $p = new WP_HTML_Tag_Processor('</br>');
 $p->next_tag( array( 'tag_closers' => 'visit' ) );
 var_dump($p->get_tag());
 if ( ! $p->is_tag_closer() ) {
   assert( null !== $p->get_attribute_names_with_prefix('') ); // Throws
 with </br>, not with </p>
 }
 }}}

 It seems inconsistent to
 - Not stop on the `</br>` if not visiting closers
 - On the `</br>` return `false` from `::is_tag_closer()`.
 - Return `null` after reporting that it's a tag opener.

 The appropriate way to handle this and what it means to be consistent is
 debatable.

 -----

 The HTML Processor uses "virtual tokens" to address this for things like
 `</p>` where a P element may be pushed to the stack and then popped. In
 that case, there's a "virtual" `<p>` followed by a "real" `</p>` and
 everything works out. `</br>` is exceptional for a few reasons:

 - It's not virtual, that token really behaves like a tag opener.
 - It's propagated all the way from the "before html" insertion mode.

 > An end tag whose tag name is "br"
 > Drop the attributes from the token, and act as described in the next
 entry; i.e. **act as if this was a "br" start tag token with no
 attributes, rather than the end tag token that it actually is.**

 -----

 What's absolutely clear is that `get_attribute_names_with_prefix()` should
 have a null check on its return value. The rest of this is nuance around
 HTML that has some issues to begin with. I don't feel strongly about the
 best path forward, but I do see inconsistencies in the way it's currently
 handled.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63891#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform