New issue
Advanced search Search tips

Issue 741826 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

In contenteditable, typing into <span> containing Tab char breaks <span> into two elements

Reported by balp...@fb.com, Jul 12 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3149.0 Safari/537.36

Steps to reproduce the problem:
1. Make a contenteditable containing a span whose first child is a text node containing a Tab (\t, &#9;) character.
2. Type into it.

What is the expected behavior?
The text you typed should be inserted into that text node.

What went wrong?
The span is broken into two pieces. This only happens if the text node contains a span.

Did this work before? Yes 

Does this work in other browsers? N/A

Chrome version: 61.0.3149.0  Channel: beta
OS Version: OS X 10.12.4
Flash Version: 

This is a recent regression. https://chromium.googlesource.com/chromium/src/+/013ac5eaf3%5E%21/ by joone.hur@intel.com broke it. I don't understand the full nuance of this change so it's hard for me to say what the proper fix was.

This broke text entry on Facebook in some cases. I'm committing a workaround to our code for this particular bug but it would be nice to have an upstream fix.
 
contenteditable-tab-splits.html
131 bytes View Download

Comment 1 by n...@fb.com, Jul 12 2017

Labels: DevRel-Facebook
Labels: Needs-Triage-M61
Cc: kkaluri@chromium.org
Labels: Needs-Feedback
Unable to reproduce the issue on Mac 10.12.5 with chrome #61.0.3149.0 with the provided html in comment #0, observed on typing text in contenteditable node didn't split into it two.

Attaching the screen-cast for reference.

balpert@ Could you please look into it and let us know your observations.

Thank You...
741826.mp4
313 KB View Download

Comment 4 by b...@benalpert.com, Aug 2 2017

kkaluri: Thanks, please open the devtools to verify. You can see that there is one <span> tag before typing and there are two <span> tags after.

The effect is not immediately user-visible but it makes no sense and can break JS event handlers relying on the DOM structure not changing.
Cc: bokan@chromium.org yosin@chromium.org
Labels: -Needs-Triage-M61 M-61 OS-Android OS-Linux OS-Windows
Cc: pbomm...@chromium.org
Status: Available (was: Unconfirmed)

Comment 7 by bokan@chromium.org, Aug 8 2017

Labels: Hotlist-Interop
Status: Untriaged (was: Available)
I've confirmed that we do split the content into two spans with an anonymous box between them with the newly typed content.

Firefox simply modifies the string inside the <span>

Moving to Untriaged so Blink editing team can investigate.
Screenshot from 2017-08-08 18:13:21.png
94.8 KB View Download

Comment 8 by bokan@chromium.org, Aug 8 2017

Owner: joone....@intel.com
Status: Assigned (was: Untriaged)
Sorry, just noticed this is a regression. Assigning to CL's owner joone.hur@. PTAL.
Labels: -M-61

Comment 10 by bokan@chromium.org, Sep 14 2017

Ping: joone.hur@, could you please take a look? This is a regression so it should be prioritised.

Comment 11 by bokan@chromium.org, Sep 25 2017

Cc: joone....@intel.com
Labels: -Pri-2 Pri-1
Owner: yosin@chromium.org
yosin@, could you please triage this, I don't have relevant expertise here to know if this is serious? It looks like joone.hur's change had unintended consequences (it looks like it was just supposed to remove some non-standard features but the regression doesn't use any of them) and we should be prioiritising regressions in behavior. Thanks.
From my perspective, this is slightly problematic because once the node is broken in half, document markers no longer draw/behave cleanly across the half (e.g. spellcheck replace no longer works properly, and composition underlines are drawn with a gap).
Components: -Blink>Editing Blink>Editing>Command
Status: Started (was: Assigned)
In review: http://crrev.com/c/697044
Project Member

Comment 14 by bugdroid1@chromium.org, Oct 5 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/52d55d36c78e4772e0e3499409dc6f6dcabde00e

commit 52d55d36c78e4772e0e3499409dc6f6dcabde00e
Author: Yoshifumi Inoue <yosin@chromium.org>
Date: Thu Oct 05 08:59:01 2017

Make InsertText command not to split SPAN element containing TAB character

Before this patch, "InsertText" command splits SPAN element containing TAB
character when inserting text into it.

For example:
Before: <span>&#9;a|c</span>
Command: insertText "B"
After: <span>&#9;a</span>B|<span>c</span>

This behavior is introduced by the patch[1], which replaces
"class=apple-tab-span" to "style=white-space:pre".

This patch changes |IsTabHTMLSpanElement()| to check "white-space:pre" CSS
property to make "InsertText" command not to split SPAN element containing
TAB character with "white-space: pre".


Note: "apple-tab-span" CSS class is MacOS specific feature[2]. On MacOS,
UITextView puts following HTML into pasteboard:

<style>.Apple-Tab-Span { white-space: pre; }</style>
<span class=Apple-Tab-Span>&#9;</span>

[1] http://crrev.com/2718543003 Remove EditingAppleTabSpan class handling
[2] https://www.cocoanetics.com/2013/06/apple-tab-span/

Bug:  741826 
Change-Id: I42d8d388e306b613fbe8ffa614b9e974db254c22
Reviewed-on: https://chromium-review.googlesource.com/697044
Commit-Queue: Yoshifumi Inoue <yosin@chromium.org>
Reviewed-by: Xiaocheng Hu <xiaochengh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#506683}
[modify] https://crrev.com/52d55d36c78e4772e0e3499409dc6f6dcabde00e/third_party/WebKit/Source/core/editing/EditingUtilities.cpp
[modify] https://crrev.com/52d55d36c78e4772e0e3499409dc6f6dcabde00e/third_party/WebKit/Source/core/editing/commands/InsertTextCommandTest.cpp

Status: Fixed (was: Started)

Sign in to add a comment