Bug 54598 – Trailing tabs in a textarea become unselectable under certain conditions

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Nick Santos]

Created attachment 82716 [details]
Reduced test case

Under certain circumstances, I can get a textarea into a state where tabs at the end of the textarea can't be selected.

It happens with certain values and not others, and depends a lot on the contents of the textarea. So I've just attached a reduced test case that demonstrates the issue.

The test fails on Chrome 9 Linux and Win (Webkit 534.13), and Safari/Win 5.03 (Webkit 533.19). You should get the alert() message:
Expected selectionEnd : 45
Actual selectionEnd : 44

[Ojan Vafai]

Nick, this is causing a bug in Google Spreadsheets, right?

In either case, it's clearly a bug.

[Nick Santos]

yes.

We care about it because when people copy-and-paste from spreadsheets, chopping off tabs at the end of Tab-Separated-Values is really bad. It drastically changes which cells are changed.

The bug only reproduces when the textarea has certain values, so our users see non-deterministic behavior.

[Ojan Vafai]

Ryosuke, did the fix for bug 56061 also fix this?

[Ryosuke Niwa]

(In reply to comment #3)
> Ryosuke, did the fix for bug 56061 also fix this?

Unfortunately not.  From what I can tell, this seems to be whitespace balancing or renderer issue.

[Ryosuke Niwa]

It seems like this is a bug in the renderer. When there's a vertical scroll bar, the length is reported wrongfully but the length is reported correctly when textarea is large enough to not have a scrollbar.

This bug affects Google Docs and we'd like it to be fixed ASAP.

[Ryosuke Niwa]

Created attachment 88057 [details]
work in progress

Here's my work in progress patch.  Will write change log entires later today.  I'm very excited to fix this bug!

[Ryosuke Niwa]

Created attachment 88080 [details]
fixes the bug

[Ryosuke Niwa]

This patch also fixes the bug 57745.  I'll add a test for the bug 57745 once this patch is landed.

[Ryosuke Niwa]

Comment on attachment 88080 [details]
fixes the bug

This patch is wrong. It'll show the space only if the line wasn't empty so you end up with a weird behavior where the trailing tab shows up on the last line but typing any other character after the tab collapses the tab again. Need to do some reading of CSS2.1 spec.

[Ryosuke Niwa]

Upon further investigation, I figured out that the bug reproduces iff word-wrap is set to break-word. So the problem doesn't reproduce in the following div:
<div style="width: 7ex; font-size: 1em; white-space: pre-wrap; -webkit-line-break: normal; word-wrap: normal;" contenteditable></div>

but reproduces in:
<div style="width: 7ex; font-size: 1em; white-space: pre-wrap; -webkit-line-break: normal;" contenteditable></div>

because contenteditable element automatically gets word-wrap: break-word.

[Ryosuke Niwa]

The bug 61484 might be a duplicate of this bug.

[Ryosuke Niwa]

*** Bug 61483 has been marked as a duplicate of this bug. ***

[Ryosuke Niwa]

http://crbug.com/83605

[Ryosuke Niwa]

I admit my defeat.  I don't know enough about line layout to be able to fix this bug in any foreseeable future.

[Ryosuke Niwa]

Created attachment 96170 [details]
test case without contenteditable attribute

[Eric Seidel (no email)]

Are we sure this isn't a regression?

[Ryosuke Niwa]

It turned out that the spec specifies whitespace wordwrap behavior:
http://www.w3.org/TR/CSS2/text.html#white-space-model

[Ryosuke Niwa]

16.6.1:
2. If 'white-space' is set to 'pre' or 'pre-wrap', any sequence of spaces (U+0020) unbroken by an element boundary is treated as a sequence of non-breaking spaces. However, for 'pre-wrap', a line breaking opportunity exists at the end of the sequence.

...
1. If a space (U+0020) at the beginning of a line has 'white-space' set to 'normal', 'nowrap', or 'pre-line', it is removed.
...
4. If spaces (U+0020) or tabs (U+0009) at the end of a line have 'white-space' set to 'pre-wrap', UAs may visually collapse them.

It's the combination of these 3 paragraphs that get us into trouble.  If we never collapsed tabs or spaces at the end of a line with 'white-space' set to 'pre-wrap', this bug will go away.

[Ryosuke Niwa]

(In reply to comment #18)
> 16.6.1:
> 2. If 'white-space' is set to 'pre' or 'pre-wrap', any sequence of spaces (U+0020) unbroken by an element boundary is treated as a sequence of non-breaking spaces. However, for 'pre-wrap', a line breaking opportunity exists at the end of the sequence.
> 
> ...
> 1. If a space (U+0020) at the beginning of a line has 'white-space' set to 'normal', 'nowrap', or 'pre-line', it is removed.
> ...
> 4. If spaces (U+0020) or tabs (U+0009) at the end of a line have 'white-space' set to 'pre-wrap', UAs may visually collapse them.
> 
> It's the combination of these 3 paragraphs that get us into trouble.  If we never collapsed tabs or spaces at the end of a line with 'white-space' set to 'pre-wrap', this bug will go away.

Uh-huh!  We're violating point 1 by applying point 4 to the leading whitespace as well.  We can fix this bug by NOT collapsing leading whitespace when 'white-space' is set to 'pre-wrap'.

[Ryosuke Niwa]

Created attachment 97045 [details]
fixes the bug

[WebKit Review Bot]

Comment on attachment 97045 [details]
fixes the bug

Attachment 97045 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/8833678

New failing tests:
fast/forms/basic-textareas-quirks.html
fast/forms/basic-textareas.html

[WebKit Review Bot]

Created attachment 97050 [details]
Archive of layout-test-results from ec2-cr-linux-03

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-03  Port: Chromium  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

[Dave Hyatt]

Comment on attachment 97045 [details]
fixes the bug

r=me

[Ryosuke Niwa]

Committed r88883: <http://trac.webkit.org/changeset/88883>

[Ryosuke Niwa]

(In reply to comment #23)
> (From update of attachment 97045 [details])
> r=me

Thanks a lot for the review!

[Ryosuke Niwa]

http://crbug.com/76111.