Open Bug 1568313 Opened 2 years ago Updated 1 month ago

Textarea wrap=hard does not actually insert newlines when posting


(Core :: DOM: Core & HTML, defect, P2)

68 Branch



Webcompat Priority ?


(Reporter: paul.pech, Unassigned)




(Keywords: regression)


(3 files)

Attached file testWrap.php

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

Posting in a textarea with wrap=hard does not insert newlines in the submitted string. This worked prior to branch 68.

Attached is a simple PHP example that shows the posted string data that was entered in a textarea.

With ESR 60.7.2 the posted data is wrapped as expected, with branch 68 it behaves as if wrap="soft" was set, that is no newlines are automatically inserted.

Actual results:

The posted and <pre> formatted data displays in a single line.

Expected results:

The posted and <pre> formatted data displays in as many lines as were shown when the data was first inserted in the textarea.

It seems this bug was introduced by changeset 473754:66cff9aa39bc (bug 1174452). Backing out that change restores expected behavior.

This change adds a test for the wrap=hard attribute on textarea elements. It ensures that POSTing a textarea with wrap=hard actually inserts a newline at the end of wrapped lines.

Hi @Paul Pech, couldn't reproduce the issue. Set component to it, if isn't the proper one please fell free to change it.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core

I've just tested again with version 68.0.1 running on Windows 7 and 10 (32bit browser) and Ubuntu 18.04 (64bit browser) and can still confirm the incorrect behavior.

Thanks @Liviu Seplecan for setting the right component.

Assignee: nobody → mbrodesser
Flags: needinfo?(mbrodesser)
Priority: -- → P2
Ever confirmed: true
Flags: needinfo?(mbrodesser)
Regressed by: 1174452

When adapting the test of comment #2 to use the string "testtest" (that is, without linebreak), no newlines are inserted. This was already the case before the change mentioned in comment #1.

Of course it still has to be fixed, but given it was already partially broken before and no one complained, this perhaps decreases the importance of it.

According to the spec "each line has no more than character width characters". So we should fix this in Gecko. However, this should be done in a separate issue.

Duplicate of this bug: 1572686

Since the spec states "If the element's wrap attribute is in the Hard state, insert U+000D CARRIAGE RETURN U+000A LINE FEED (CRLF) character pairs into the string using a UA-defined algorithm so that each line has no more than character width characters. " we'll need a Gecko-specific test (presumably Mochitest) for this.

According to spec, this is UA-specific, hence this is a Mochitest and
not a WPT.

Gecko doesn't split words exceeding the width, hence this is also not
asserted. This violates the spec and should be dealt with separately.

Given my knowledge and the current, messy, state of nsPlainTextSerializer, I'm not able to fix this issue without possibly introducing other regressions.

I've cleaned up parts of nsPlainTextSerializer, but it needs presumably significantly more clean-up before the issues is fixable.

As I've other duties, I'll stop the work on this issue.

Assignee: mbrodesser → nobody

Sorry to bother you.
For my factory is important the solution.
I have 100 user connected to our intranet with Firefox and a lot of programs have this situation in textareas.
Do you think when the solution will be resolved ?
The problem really exists, can a person to be assigned to this problem ?
version 69.0.2
Many thanks

Do you have an idea when the problem will be resolved ?

+1 to the list of people being affected by this.

We're using the Roundup Issue Tracker. Tickets submitted via Firefox (in our case the ESR version on Debian) already have very long lines.
I don't want to tell our users to use Chromium, they should have a free choice (and I prefer Firefox).

Or should we implement server-side word wrap in Roundup or client-side with Javascript?

Webcompat Priority: --- → ?

I see this bug vor all versions 68 and higher, including the new 71.0
I really hope, somebody is able and willing, to correct this.

Unfortunately, there's presumably nobody able to quickly fix this bug. The code is partially very old (year 2000?). We consider to reinvestigate it end of January 2020.

Duplicate of this bug: 1644182

This is unfortunately still present in the very latest browser (I'm using 82.0.3, currently).

Just as Thomas said in comment #13, some of our users are using Firefox on open platforms where Firefox is by far their best browser choice. It would be really great to have this issue prioritized.

We'll reconsider the priority. Unfortunately, this issue seems hard to fix.

Thanks Mirko.

Duplicate of this bug: 1680619
You need to log in before you can comment on or make changes to this bug.