Interactivity API: Fix directives in tags whose closing tag is not visited not working

[SantosGuillamot]

Trac ticket: https://core.trac.wordpress.org/ticket/60746

Right now, if I add directives to tags with closing tag that is not visited by the tag processor, it breaks the whole server-side rendering processing.

This is the list of those tags:

wordpress-develop/src/wp-includes/interactivity-api/class-wp-interactivity-api-directives-processor.php

Lines 25 to 34 in 186eeaf

	const TAGS_THAT_DONT_VISIT_CLOSER_TAG = array(
	'SCRIPT',
	'IFRAME',
	'NOEMBED',
	'NOFRAMES',
	'STYLE',
	'TEXTAREA',
	'TITLE',
	'XMP',
	);

For example, if I try to add a directive to an iframe, it breaks the processing.

Co-authored by @cbravobernal

---

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.

[github-actions]

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 props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props santosguillamot, mukesh27, westonruter, swissspidy, dmsnell.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[swissspidy]

cc for review: @luisherranz, maybe @westonruter too

[westonruter]

Could this test be expanded (or another one added) which test that the absence of the new if condition does indeed cause breaking the whole server-side rendering processing as described?

[SantosGuillamot]

Not sure if I understand what you mean. The existing test already checks that the SSR doesn't break when there is an iframe. The same test was failing without the final solution.

By the way, I've reverted the if condition because it is solved by another PR as explained here.

[westonruter]

I thought that there were wider breakages than just with a single element. So that's what I thought would be good to test.

[dmsnell]

After a lot of debugging I'm wondering if the IFRAME is a red herring and the problem is that we have directive processors that don't handle elements without closing tags. For example, I added a test which adds context on an IMG element and it also failed to process in the same way that the test added here fails.

<div data-wp-context='{"text": "outer"}'>
<img data-wp-context='{"text": "inner"}'>
<p data-wp-text="context.text"></p>
</div>

and then in the test I call do_blocks() on the HTML without doing anything else

Or these tests simply aren't running the server directive processor because when I output the input $html I'm not seeing that in the logs, only for two of the tests in the wpInteractivityApiFunctions.php suite - _of_single_interactive_block() and _only_process_the_root_interactive_block

[dmsnell]

please ignore my last comment: I finally reproduced this and I think I can say that it's fixed already in #6120, which is supposed to go in to 6.5 anyway, and this gives it even more reason to do so.

what's happening?

once the attribute was updated and next_tag() is called, the Tag Processor applies the changes and then re-parses content. it wasn't doing that properly once it started scanning all tokens, because it was short-circuiting some logic to avoid sub-class methods from being called (e.g. you don't want WP_HTML_Processor::next_token() to be called and then mess with the HTML stack of open elements).

unfortunately this short-circuit was programmed with the old assumption that everything is a tag, and we missed updating it earlier in the cycle for all tokens, including the handling of special tokens.

in #6120 the Tag Processor creates its own internal base_class_next_token() that it calls so that all of the logic is repeated after applying updates and seeking. this resolves the issue here because it then is able to trap the start and end of the iframe tag as one token.

[dmsnell]

This branch, without the proposed fix, but with the deferred updates PR passes the tests.
#6250

[SantosGuillamot]

Thanks a lot for taking a deeper look at it, @dmsnell ☺️

I've rebased trunk and reverted the proposed fix and I can confirm that the test passes now. I'll leave this pull request only with the new test to ensure it keeps working as expected in the future.

[dmsnell]

Merged in [57822]
b1b97f9