| Summary: | Trailing tabs in a textarea become unselectable under certain conditions | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Nick Santos <nicksantos> | ||||||||||||||
| Component: | Layout and Rendering | Assignee: | Ryosuke Niwa <rniwa> | ||||||||||||||
| Status: | RESOLVED FIXED | ||||||||||||||||
| Severity: | Normal | CC: | adele, bdakin, darin, dglazkov, enrica, eric, hyatt, justin.garcia, komoroske, leviw, mitz, ojan, peterbraden, rniwa, rolandsteiner, webkit.review.bot, xji | ||||||||||||||
| Priority: | P2 | Keywords: | GoogleBug, HasReduction | ||||||||||||||
| Version: | 528+ (Nightly build) | ||||||||||||||||
| Hardware: | All | ||||||||||||||||
| OS: | All | ||||||||||||||||
| Bug Depends on: | |||||||||||||||||
| Bug Blocks: | 57745, 61483 | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
Nick, this is causing a bug in Google Spreadsheets, right? In either case, it's clearly a bug. 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. (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. 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. 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!
Created attachment 88080 [details]
fixes the bug
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.
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. The bug 61484 might be a duplicate of this bug. *** Bug 61483 has been marked as a duplicate of this bug. *** I admit my defeat. I don't know enough about line layout to be able to fix this bug in any foreseeable future. Created attachment 96170 [details]
test case without contenteditable attribute
Are we sure this isn't a regression? It turned out that the spec specifies whitespace wordwrap behavior: http://www.w3.org/TR/CSS2/text.html#white-space-model 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. (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'. Created attachment 97045 [details]
fixes the bug
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 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
Comment on attachment 97045 [details]
fixes the bug
r=me
Committed r88883: <http://trac.webkit.org/changeset/88883> (In reply to comment #23) > (From update of attachment 97045 [details]) > r=me Thanks a lot for the review! |
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