[wp-trac] [WordPress Trac] #64609: HTML API: set_modifiable_text() ignores leading newlines in TEXTAREA (was: HTML API: set_modifiable_text() ignores leading newlines in PRE, LISTING, TEXTAREA)

WordPress Trac noreply at wordpress.org
Mon Mar 2 12:57:53 UTC 2026


#64609: HTML API: set_modifiable_text() ignores leading newlines in TEXTAREA
--------------------------------------+-------------------------
 Reporter:  jonsurrell                |       Owner:  jonsurrell
     Type:  defect (bug)              |      Status:  closed
 Priority:  normal                    |   Milestone:  7.0
Component:  HTML API                  |     Version:  6.7
 Severity:  minor                     |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------
Changes (by jonsurrell):

 * status:  assigned => closed
 * resolution:   => fixed


Old description:

> The `::set_modifiable_text()` method on `WP_HTML_Tag_Processor` and
> `WP_HTML_Processor` will fail to include a leading newline in the
> provided plaintext content on the first text of `TEXTAREA`, `PRE`, and
> `LISTING` elements.
>
> This is due to special rules for these elements that cause a single
> leading newline to be ignored immediately following the open tag.
>
> {{{#!php
> <?php
> $html_processor =
> WP_HTML_Processor::create_fragment('<textarea></textarea>');
> $html_processor->next_token();
> $html_processor->set_modifiable_text( "\nAFTER NEWLINE" );
> var_dump( $html_processor->get_modifiable_text() );
> // string(13) "AFTER NEWLINE"
> echo $html_processor->get_updated_html();
> /* Prints:
> <textarea>
> AFTER NEWLINE</textarea>
> */
> }}}
>
> Note that the newline is present in the updated HTML, however the HTML
> parsing rules cause the leading newline to be ignored.
>
> When rendered in the browser, this `TEXTAREA` element will report its
> `.textContent` as `AFTER NEWLINE` (with no leading newline) and the
> rendered element shows `AFTER NEWLINE` on the first line of the input
> box.
>
> In order for the `TEXTAREA` to begin with a newline in its content, an
> additional newline must be included.
>
> This is closely related to #64607.

New description:

 The `::set_modifiable_text()` method on `WP_HTML_Tag_Processor` and
 `WP_HTML_Processor` will fail to include a leading newline in the provided
 plaintext content on the first text of `TEXTAREA` elements.

 This is due to special rules for `TEXTAREA` elements that cause a single
 leading newline to be ignored immediately following the open tag.

 {{{#!php
 <?php
 $html_processor =
 WP_HTML_Processor::create_fragment('<textarea></textarea>');
 $html_processor->next_token();
 $html_processor->set_modifiable_text( "\nAFTER NEWLINE" );
 var_dump( $html_processor->get_modifiable_text() );
 // string(13) "AFTER NEWLINE"
 echo $html_processor->get_updated_html();
 /* Prints:
 <textarea>
 AFTER NEWLINE</textarea>
 */
 }}}

 Note that the newline is present in the updated HTML, however the HTML
 parsing rules cause the leading newline to be ignored.

 When rendered in the browser, this `TEXTAREA` element will report its
 `.textContent` as `AFTER NEWLINE` (with no leading newline) and the
 rendered element shows `AFTER NEWLINE` on the first line of the input box.

 In order for the `TEXTAREA` to begin with a newline in its content, an
 additional newline must be included.

 This is closely related to #64607.

--

Comment:

 I've created #64776 to track the issue for `PRE` and `LISTING`. I don't
 expect those to be addressed in 7.0.

 This ticket now focuses specifically on `TEXTAREA`.

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


More information about the wp-trac mailing list