Regression in `wp.sanitize.stripTags()` in WordPress 7.0-alpha

[hugod]

wp.sanitize.stripTags() doesn't return the same value when given null.

With WordPress 6.9:

console.log( 'testStripTagsWithNull', wp.sanitize.stripTags( null ) ); // ""
console.log( 'typeofResult', typeof wp.sanitize.stripTags( null ) ); // string

With WordPress 7.0-alpha:

console.log( 'testStripTagsWithNull', wp.sanitize.stripTags( null ) ); // "null"
console.log( 'typeofResult', typeof wp.sanitize.stripTags( null ) ); // string

Leading to unexpected behavior in wp.sanitize.stripTagsAndEncodeText() as well...

I think the regression has been introduced in ​https://github.com/WordPress/wordpress-develop/commit/3865859fd8982575204bc04e77197ea4c743ccf5.

…

Ensure that wp.sanitize.stripTags() returns an empty string when the input is null or undefined, preventing it from being converted to the string "null" by DOMParser.

Added regression tests.

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

[westonruter]

@hugod Thanks for reporting this.

This indeed was introduced in [60907] to fix #48054.

I have an initial PR to fix the issue here available for testing and review: ​https://github.com/WordPress/wordpress-develop/pull/10833

[westonruter]

Actually, the regression wasn't introduced in [60907] but rather in [61347] to fix #64274.

@westonruter Can you share testing steps please?

@mukeshpanchal27 the ticket description has the reproduction info. I guess go to a screen where that script is enqueued, or enqueued the script yourself, and then run the function in the console.

[westonruter]

In 61578:

General: Preserve back-compat for wp.sanitize.stripTags() to return empty string when passed null/undefined.

This also bumps the esversion to 11 in tests/qunit/.jshintrc to match the root .jshintrc, following [61544] for #64562.

Follow-up to [61347], [60907].

Props westonruter, jonsurrell, mukesh27, hugod.
See #64274.
Fixes #64574.

Follow-up to:

• @sirreal: ​https://github.com/WordPress/wordpress-develop/pull/10833#discussion_r2758059447
• @Hug0-Drelon: ​https://github.com/WordPress/wordpress-develop/pull/10833#discussion_r2757723749

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

[westonruter]

In 61585:

General: Further preserve back-compat for wp.sanitize.stripTags() to return empty string when falsy value supplied.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/10856

Follow-up to [61578], [61347], [60907].

Props jonsurrell, hugod, westonruter.
See #64274.
Fixes #64574.

See ​https://github.com/WordPress/wordpress-develop/pull/10833#discussion_r2833992103:

I’m late to the game, but do we expect any other type errors? I suppose we expect people to send things that are strings nominally, but may be missing.

However, if we make a _positive assertion_ we wouldn’t have to chase this later.

if ( 'string' !== typeof $text ) {
        return '';
}

It turns out that passing a non-string in 6.9 would cause an error due to the replace() method not being available on it (probably). So the previous change in r61578 which added support for sanitizing numbers actually would have previously caused an error. So we can indeed just short-circuit when a non-string is passed.

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

## Use of AI Tools

None

@Hug0-Drelon How does this work for you?

@westonruter LGTM 👍

I've looked at 6.8.3, and the regression seems to be that any falsy value is treated as the string `''`:

let _text = text || '';

As such, numbers (aside from 0) would error because of the missing .replace() method and don't need to be handled here.

[westonruter]

In 61783:

General: Update wp.sanitize.stripTags() to return empty string when not passed a string.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/10994

Follow-up to r61585, r61578.

Props westonruter, jonsurrell, dmsnell, hugod.
See #64574, #64274.

Committed in r61783 (7e46834)