New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 656866 link

Starred by 1 user
Status: Available
Owner: ----
Cc:
tkent@chromium.org
kojii@chromium.org
█ sureshkumari@chromium.org
editing-dev@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug-Regression



Sign in to add a comment

Selection loss in a contenteditable div when using the formatBlock command

Reported by charles...@gmail.com, Oct 18 2016 
UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36

Steps to reproduce the problem:

1. Create a parent div.
2. Create 2 child divs inside the first one.
3. Assign inline-block as display to those 3 divs (parent and childs).
4. Add a :before pseudo element to the 2 child divs.
5. Set the content of the 2 :before pseudo elements.
6. Insert a comment between the 2 child divs to remove the default spacing that occurs by having, in the html code, a linebreak between 2 inline elements.
7. Create a contenteditable div after the div created at step 1.
8. Select some text in the contenteditable div.
9. Execute the execCommand function with the 'formatBlock' command.

Please see the attached reduced test case.

What is the expected behavior?
The selected text should remain selected after the command execution.

What went wrong?
The selected text is deselected after the command execution.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 54.0.2840.59  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 23.0 r0
selectionLoss.html
996 bytes View Download

Comment 1 Deleted

Comment 2 by sureshkumari@chromium.org, Oct 19 2016

Labels: -Type-Bug -Pri-2 M-56 Pri-1 Type-Bug-Regression
Able to reproduce the issue on windows-7,windoes-10 and Mac 10.11.4 using chrome stable version 54.0.2840.59 and  canary 56.0.2891.0

This is regression issue broken in M50.Please find the bisect information as below

Narrow Bisect::
===============
Good ::50.0.2652.0   --   (build revision 375497)
Bad::50.0.2654.0 --   (build revision 376054)

ChangeLog: 
================
https://chromium.googlesource.com/chromium/src/+log/3f0cbf682e7dfe5ee8ebc171e473cece02c6c3cc..4d4b5a804549c1f0856d6346309bc72c823692c7


Possible suspect
==================
19bbcfa6c724690ed4aa246ba64c496707f91bbb


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


dtseng@ 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,

Comment 3 by dtseng@chromium.org, Oct 24 2016

NextAction: 2016-10-24
Owner: ----
Status: available (was: Assigned)
Extremely unlikely I caused this regression (my change was only a few lines and specific to accessibility). Any chance you could look through the other cl's and revert/build to do a manual bisect over that range?

Comment 4 by kojii@chromium.org, Nov 29 2016

Cc: tkent@chromium.org
More likely this one:
https://codereview.chromium.org/1702233002

Comment 5 by kojii@chromium.org, Nov 29 2016

Labels: -OS-Windows -OS-Mac OS-All
NextAction: ----
Owner: kojii@chromium.org
Status: Started (was: Available)

Comment 6 by kojii@chromium.org, Dec 2 2016

Cc: kojii@chromium.org yosin@chromium.org
Owner: ----
Status: Available (was: Started)
WIP here
https://codereview.chromium.org/2532373002

yosin@ said the code looks good but wanted to polish the test better, and he's taking this over.

Comment 7 by rbasuvula@chromium.org, Dec 19 2016 

@yosin: Friendly reminder, Could you please take a look on it.

Comment 8 by tkonch...@chromium.org, Jan 2 2017 

This issue is still seen on win10 latest canary 57.0.2969.0
Working fine on Firefox browser

@yosin: Gentle Ping!

Could you please take a look.

Comment 9 by krajshree@chromium.org, Jan 9 2017 

Just to update, still able to reproduce this issue on Win-10 using latest canary #57.0.2976.0.

yosin@ - Friendly Ping...!!

Could you please have a look into this issue.

Thanks...!!

Comment 10 by krajshree@chromium.org, Jan 17 2017 

Just to update, still able to reproduce this issue on mac 10.12.2 using latest canary #57.0.2983.0.

yosin@ - Could you please have a look into this issue.

Thanks...!!

Comment 11 by tkonch...@chromium.org, Jan 23 2017 

Just to update, still able to reproduce this issue on win10 using latest canary #58.0.2989.0

yosin@ - Could you please take a look

Comment 12 by kojii@chromium.org, Jan 27 2017

Owner: yosin@chromium.org
Status: Assigned (was: Available)
yosin@, if you're ok to land the CL in #4 as is, and me to file a bug to improve tests later for you, please let me know.

You don't want to revert https://codereview.chromium.org/1702233002, do you?

Comment 13 by yosin@chromium.org, Jan 27 2017

Cc: -yosin@chromium.org
Labels: -Pri-1 Pri-2
Lower to Pri-2 since real world usage of FormatBlock is very low < 0.0199%

Note: component>Blink>Editing is automatically forward to yosin@

Comment 14 by yosin@chromium.org, Mar 23 2017

Owner: ----
Status: Available (was: Assigned)

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

Labels: Pri-3

Comment 16 by xiaoche...@chromium.org, Nov 13 2017

Components: Blink>Editing>Command
Project Member

Comment 17 by sheriffbot@chromium.org, Nov 14

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 18 by yosin@chromium.org, Nov 19

Status: Available (was: Untriaged)
►

Sign in to add a comment