2003109 - Textarea wrap=hard: The behavior differs from Chrome. Unintended line breaks are inserted.

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Alice0775 White]

Attachment: testcase.html

STR:

1. download the attached textcase.html to local disk.
2. Open downloaded textcase.html
3. Paste the following text to the textarea

.2.4.6.8 2.4.6.8 2.4.6.8 2.4.6.8 2.4.6.8 2.4.6.8 
.2.4.6.8 2.4.6.8 2.4.6.8 
.2.4.6.8 2.4.6.8 2.4.6.8 2.4.6.8 2.4.6.8

4. click

Actual Results:

• Before Bug 2002971

.2.4.6.8 2.4.6.8 2.4.6.8 2.4.6.8 2.4.6.8 2.4.6.8 

.2.4.6.8 2.4.6.8 2.4.6.8 
.2.4.6.8 2.4.6.8 2.4.6.8
2.4.6.8 2.4.6.8

• After Bug 2002971

.2.4.6.8 2.4.6.8 2.4.6.8 2.4.6.8 2.4.6.8 2.4.6.8 
.2.4.6.8 2.4.6.8 2.4.6.8 
.2.4.6.8 2.4.6.8 2.4.6.8
2.4.6.8 2.4.6.8

Expected Results: (Chrome does)

.2.4.6.8 2.4.6.8 2.4.6.8 2.4.6.8 2.4.6.8 2.4.6.8 
.2.4.6.8 2.4.6.8 2.4.6.8 
.2.4.6.8 2.4.6.8 2.4.6.8 2.4.6.8 2.4.6.8

So, Bug 2002971 does not fix this the extra line break in some case.

Comment 1

[Alice0775 White]

emilio, could you please look into this?

Comment 2

[Alice0775 White]

Attachment: testcase2.html

Here, a more realistic example: hard-wrap at 80 columns.

STR:

1. Paste the following text to the textarea

function loadError(oError) {
  throw new URIError(`The script ${oError.target.src} didn't load correctly.`);
}

function prefixScript(url, onloadFunction) {
  const newScript = document.createElement("script");
  newScript.onerror = loadError;
  if (onloadFunction) {
    newScript.onload = onloadFunction;
  }
  document.currentScript.parentNode.insertBefore(
    newScript,
    document.currentScript,
  );
  newScript.src = url;
}

2. click

AR:

/*Let's create a function that imports new scripts within a document creating a
<script> node immediately before the <script> that hosts the following code. */

function loadError(oError) {
  throw new URIError(`The script
${oError.target.src} didn't load correctly.`);
}

function prefixScript(url,
onloadFunction) {
  const newScript = document.createElement("script");

 newScript.onerror = loadError;
  if (onloadFunction) {
    newScript.onload =
onloadFunction;
  }
  document.currentScript.parentNode.insertBefore(

   newScript,
    document.currentScript,
  );
  newScript.src = url;
}

ER:
In this case, only the first line of the comment should be hard-wrapped.
Each line in the section of JavaScript code is already under 80 columns, so no additional line breaks should be needed.

<script> node immediately before the <script> that hosts the following code. */

function loadError(oError) {
  throw new URIError(`The script ${oError.target.src} didn't load correctly.`);
}

function prefixScript(url, onloadFunction) {
  const newScript = document.createElement("script");
  newScript.onerror = loadError;
  if (onloadFunction) {
    newScript.onload = onloadFunction;
  }
  document.currentScript.parentNode.insertBefore(
    newScript,
    document.currentScript,
  );
  newScript.src = url;
}

Comment 3

[Alice0775 White]

Input the following text into testcase2.html. then click

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
aaaaa
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

AR:
The long sentence on the second line breaks at an unintended point.
if the input text contains pre-formatted lines(here aaaaa\d\n) shorter than the default, subsequent longer lines may break unexpectedly.

Apparently, The length of a pre-formatted short line and the length immediately preceding a line are incorrectly considered when determining the break position for the next long line.

Comment 4

[RobD]

From what I saw, if you use Wrap=Hard and Cols=75 then it will put a line break in at 75 (73 chars + 2 for CR code) even if this covers several lines of text.

In other words, instead of it reading Cols=75 as "put CR in at 75 chars if NOT already had one by then", it appears to be reading it as "put a CR in at 75 chars even if its already had one before then" and then after putting in one of these unneeded extra CR's, it starts counting back up to 75 again before putting in another unneeded CR (with slight adjustment to add the CR code itself).

In terms of versions, I've heard reports it works normally on Firefox v144, but failing on Firefox v145, suggesting it may be something new with v145. However none of the changes listed in v145 obviously relate, so unclear why that would be the case.

Comment 5

[Tim Mooney]

I can confirm that we're seeing unintended breaks in textareas with the new wrap=hard behavior in firefox. For us, the new behavior is unfortunately worse than when wrap=hard didn't work at all.

What we're seeing matches the behavior that RobD and Alice0775 White outlined.

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Sorry for the lag, I've been swamped with other higher priority work. Looking at this now.

Comment 8

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2003109 - Improve textarea hard-wrapping further. r=smaug,#dom-core

Turns out there are still various issues:

• There's this "bonus width" thing which might make us actually not
  hard-wrap. Add an option to ignore it.

• Even though \n does create a breaking opportunity, we don't
  force-break. Do deal with each line at a time instead.

It's technically a bit more inefficient (two passes over the string),
but seems fine and it's simpler / easier to prove correct.

Add a few extra tests too.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/762fa5256f74
https://hg.mozilla.org/integration/autoland/rev/8045ed5e41d0
Improve textarea hard-wrapping further. r=hsivonen

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/57255 for changes under testing/web-platform/tests

Comment 11

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/8045ed5e41d0

Comment 12

[BugBot [:suhaib / :marco]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 13

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 14

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox148 to wontfix.

For more information, please visit BugBot documentation.

Comment 15

[Emilio Cobos Álvarez [:emilio]]

Comment on attachment 9538296 [details]
Bug 2003109 - Improve textarea hard-wrapping further. r=smaug,#dom-core

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Regression with duplicates, and we're early-ish in the cycle.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: comment 2 is a realistic test-case.
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Change only affects this feature and nothing else.
• String changes made/needed: none
• Is Android affected?: Yes

Comment 16

[Donal Meehan [:dmeehan]]

Comment on attachment 9538296 [details]
Bug 2003109 - Improve textarea hard-wrapping further. r=smaug,#dom-core

Approved for 148.0b6

Comment 17

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/f24ac8b0310c
https://hg.mozilla.org/releases/mozilla-beta/rev/90e149ee7863

Comment 18

[Peter Magyari (Desktop QA)]

Verified fixed using Nightly 149.0a1 (20260122072819) and Beta 148.0b6 (20260121193655) on Windows 11, MacOS 15 and Ubuntu 24.04.