New issue
Advanced search Search tips

Issue 669229 link

Starred by 2 users

Issue metadata

Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 3
Type: Bug-Regression



Sign in to add a comment

contenteditable loses selection near inline non-editable element

Reported by alex...@gmail.com, Nov 28 2016

Issue description

Chrome Version       : 54.0.2840.99
OS Version: 10.0
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
      Safari 5: (not tested)
  Firefox 50.0: OK
         IE 11: OK

What steps will reproduce the problem?
1. open attached contenteditable2.html
2. click on "editable1"
3a. press and hold right arrow
  ... or ...
3b. press [End]

What is the expected result?
* text selection to move after "readonly1" and stop 

What happens instead of that?
1) selection goes up to "readonly1", then jumps to "editable2"
2) after moving right over "editable2", selection disappears

Please provide any additional information below. Attach a screenshot if
possible.

* This is new in Chrome 54
* IE and Firefox show other bugs on this test, but neither loses selection
* Observing selection in DOM shows that it is in the first text node after non-editable element, even if it is far outside contenteditable


UserAgentString: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36



 
contenteditable2.html
176 bytes View Download

Comment 1 by tkent@chromium.org, Nov 28 2016

Components: Blink>Editing
Labels: -Type-Bug Needs-Bisect Type-Bug-Regression
Labels: -Pri-3 M-54 Needs-Triage-M54 Pri-1

Comment 3 by yosin@chromium.org, Nov 29 2016

Components: -Blink>Editing Blink>Editing>Selection
Labels: -Pri-1 OS-Android OS-Chrome OS-Linux OS-Mac Pri-2
Status: Available (was: Unconfirmed)
Lower to Pri-2, since selection with uneditable elements is existing issue. 
We'll revise visible position canonicalization on 2017.
Labels: -Needs-Bisect hasbisect-per-revision
Owner: joone....@intel.com
Status: Assigned (was: Available)
Able to reproduce the issue on windows-7, Mac-10.11.6 and Linux Ubuntu 14.04 using chrome stable version 54.0.2840.99 and canary 57.0.2937.0
This is regression issue broken in M54.Please find the bisect information as below

Narrow Bisect::
===============
Good :54.0.2832.0 --   (build revision 412743)
Bad:: 54.0.2833.0 --   (build revision 413134)

ChangeLog: 
================
https://chromium.googlesource.com/chromium/src/+log/be005133f3f7f1aa3725f532c73d0470e804b70b..f15d4cc339737df653274e39726ae0d14d409b18

possible suspect
==================
f15d4cc339737df653274e39726ae0d14d409b18

Review URL: https://codereview.chromium.org/2250133004

joone.hur@ could you please look into this issue if it is related to your change,else please help us in finding the appropriate owner for this issue.

Thanks.

sureshkumari@ Okay, I will look into the problem.
Status: Started (was: Assigned)

Comment 8 by yosin@chromium.org, Oct 4 2017

Labels: Pri-3

Sign in to add a comment