Open Bug 1568313 Opened 5 years ago Updated 1 year ago

Textarea wrap=hard does not actually insert newlines when posting

Categories

(Core :: DOM: Forms, defect, P2)

68 Branch
defect

Tracking

()

Webcompat Priority P3

People

(Reporter: paul.pech, Unassigned)

References

(Regression, )

Details

(Keywords: regression)

Attachments

(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.
Thanks.

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
Status: UNCONFIRMED → ASSIGNED
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.

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
Status: ASSIGNED → NEW

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

HI TO ALL
Do you have an idea when the problem will be resolved ?
Thanks

+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: --- → ?

Hi!
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.

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.

The line wrapping is not too performance-sensitive (i.e. we could tolerate conversions from UTF-16 to UTF-8 and back). Also, for textarea (as opposed to mailnews HTML to plain text conversion that has historically complicated this code), it could be a function with a very simple interface: Takes a string and an integer and returns a string. That is, the function decides where in the given string to insert line feeds.

On surface, a string manipulation function with such a simple interface is well suited for a small Rust crate. The main issue regardless of implementation language is that we don't duplicate Unicode data that we already are carrying / going to carry otherwise.

The line wrap function takes a line wrap limit in terms of East Asian Width. Also, when a run of text between two spaces is longer in terms of East Asian Width than the expressed line width, something special needs to happen. If we're changing things in this area, it might be more worthwhile to imitate Chrome for what that is instead of trying to do what our old code did. In our old code, what happens seems to implicate Japanese (and, as a side effect, AFAICT, Chinese) and Thai language-dependent line breaking.

Zibi, if we were to rewrite this as a tiny crate on top of ICU4X, what timeline do we except for ICU4X-based line breaking to become available to Gecko in such a way that a tiny crate here indeed would be tiny in terms what it would add to Gecko and for ICU4X-based East Asian Width measurement?

Flags: needinfo?(zbraniecki)

Zibi, if we were to rewrite this as a tiny crate on top of ICU4X, what timeline do we except for ICU4X-based line breaking to become available to Gecko in such a way that a tiny crate here indeed would be tiny in terms what it would add to Gecko and for ICU4X-based East Asian Width measurement?

My expectation is Q3

Flags: needinfo?(zbraniecki)

Does https://github.com/whatwg/html/issues/6662 substantially alter the landscape here? It seems that Chrome and Safari rely on layout text wrapping and then insert newlines when layout decides to wrap. (As Andreu pointed out on IRC, this might be another case where Hixie ignored the status quo: https://lists.w3.org/Archives/Public/public-whatwg-archive/2006Aug/0082.html.)

Component: DOM: Core & HTML → DOM: Forms
Flags: needinfo?(hsivonen)

(In reply to Anne (:annevk) from comment #23)

Does https://github.com/whatwg/html/issues/6662 substantially alter the landscape here? It seems that Chrome and Safari rely on layout text wrapping and then insert newlines when layout decides to wrap. (As Andreu pointed out on IRC, this might be another case where Hixie ignored the status quo: https://lists.w3.org/Archives/Public/public-whatwg-archive/2006Aug/0082.html.)

Whoa! That's news to me. It indeed requires re-thinking how to approach this!

Flags: needinfo?(hsivonen)

Masayuki, what would we need to do to ask layout for the line breaks?

Flags: needinfo?(masayuki)

(In reply to Henri Sivonen (:hsivonen) from comment #25)

Masayuki, what would we need to do to ask layout for the line breaks?

Well, <textarea> (and <input>) has only one text node in the anonymous subtree. Therefore, I think that it's not so hard if we ignore bidi text. In my understanding, an nsTextFrame is created per line. So, inserting CRLF after every nsTextFrame almost work. If there is a way to distinguish the line difference between multiple nsTextFrames in a line, we can treat the bidi text correctly.

Jonathan Kew must have better knowledge than me. Can we simply create multiline text which is WYSIWYG from the <textarea>'s layout information?

(I wonder, when we need to submit the text from an event listener, we may need to flush layout newly before computing the submitting text. It might cause some edge cases between browsers.)

Flags: needinfo?(masayuki) → needinfo?(jfkthame)

Thanks. It would be good to check what Blink and WebKit do about bidi.

It seems like it should be possible to find the block frame that's generated for the textarea contents, iterate over its list of lines, and for each line, iterate over its frames (often only one), generating the corresponding text and then adding CRLF before the next line.

It's unclear to me what would be the "right" thing to do for bidi content, in general. It would seem natural to output the text in the order we're displaying it; but if the receiving system re-applies the bidi algorithm to the content of each line, things may get flipped around. "Hard wrapping" of mixed-direction content seems like an inherently problematic idea, and probably should be discouraged.

Flags: needinfo?(jfkthame)

Thank you for quick reply!

(In reply to Jonathan Kew (:jfkthame) from comment #28)

It seems like it should be possible to find the block frame that's generated for the textarea contents, iterate over its list of lines, and for each line, iterate over its frames (often only one), generating the corresponding text and then adding CRLF before the next line.

Did you mean that do not we have the internal API to list up the lines?

It's unclear to me what would be the "right" thing to do for bidi content, in general. It would seem natural to output the text in the order we're displaying it; but if the receiving system re-applies the bidi algorithm to the content of each line, things may get flipped around. "Hard wrapping" of mixed-direction content seems like an inherently problematic idea, and probably should be discouraged.

Well, if RTL word in a LTR <textarea>, and the work is split by line, I'm not sure what we should do...

(In reply to Henri Sivonen (:hsivonen) from comment #27)

Thanks. It would be good to check what Blink and WebKit do about bidi.

Yeah, it is.

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #29)

Thank you for quick reply!

(In reply to Jonathan Kew (:jfkthame) from comment #28)

It seems like it should be possible to find the block frame that's generated for the textarea contents, iterate over its list of lines, and for each line, iterate over its frames (often only one), generating the corresponding text and then adding CRLF before the next line.

Did you mean that do not we have the internal API to list up the lines?

I don't know if we have some suitable API already (maybe there's something in Editor that would be useful?). If not, we at least have nsBlockFrame::Lines(), so we can write a loop over the lines of the block and process each one, starting with its mFirstChild and following the sibling pointers. Given that we know there will only be text frames (and maybe <br> frames?) in the line (not arbitrary inline content, out-of-flows, etc.), it shouldn't be too complex, I think.

Thanks. It seems enough for this bug. (When I worked on around text-decoration, I understood as the line information is available only during reflow for footprint.)

But I wonder, if the <textarea> is invisible (i.e., frames are not created), I have no idea what we should do. Needs investigating the other browsers before writing/reviewing patches for this bug.

Do we know if there are public sites which are broken because of this? We don't know any so far from the webcompat team perspective.

Webcompat Priority: ? → P3
Flags: needinfo?(hsivonen)

(In reply to Karl Dubost💡 :karlcow from comment #32)

Do we know if there are public sites which are broken because of this? We don't know any so far from the webcompat team perspective.

Some public Roundup instances, e.g. https://issues.roundup-tracker.org/ (but not bugs.python.org, they don't use wrap=hard).
I added a long line to it (msg7420):
https://issues.roundup-tracker.org/issue2551070
The text is displayed with CSS white-space: pre-wrap, but this will not wrap some lines, e.g. long base64 encoded URLs. When this happens, the message boxes become as wide as the widest message, thus breaking the wrapping for other messages that otherwise display fine, too.

In our own installations (which are not public) I now use CSS "word-break: break-word;", which solves our problem there, but I think this is CSS3-only, so maybe can't be expected to be used with older sites? On the other hand the oldest supported Firefox ESR now supports this (I think it was introduced in Firefox 67) and other browers that still receive security updates, too, so this is not as critical as it was before.

(In reply to Karl Dubost💡 :karlcow from comment #32)

Do we know if there are public sites which are broken because of this? We don't know any so far from the webcompat team perspective.

I don't know. Sorry.

Flags: needinfo?(hsivonen)
Has Regression Range: --- → yes
Severity: normal normal → S3 S3
You need to log in before you can comment on or make changes to this bug.