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

Issue 771772 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: 2017-10-19
OS: Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

document.queryCommandState returns false after execCommand followed by clicking inside editor

Reported by sam.b...@curvedental.com, Oct 4 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.38 Safari/537.36

Steps to reproduce the problem:
Can be reproduced in a number of rich text editors that can be found online. Two examples these steps work on:
- http://www.writeurl.com/ (click 'NEW DOCUMENT')
- https://dojotoolkit.org/reference-guide/1.10/dijit/Editor.html (click any 'Run' button)

1. Type in some text and click to move the cursor anywhere on the line.
2. Choose some formatting (e.g. bold)
3. Click on the cursor position again.

What is the expected behavior?
The formatting should stay selected.

What went wrong?
The selected formatting reverts to the text surrounding the cursor position.

Did this work before? Yes 61.0.3163.100 (any time between then and 62.0.3202.38)

Does this work in other browsers? Yes

Chrome version: 62.0.3202.38  Channel: n/a
OS Version: 10.0
Flash Version:
 
Labels: Needs-Bisect Needs-Triage-M62
Cc: hdodda@chromium.org
Labels: Needs-Feedback
Tested the issue on windows 10 using chrome M61 #61.0.3163.100 and latest beta M63 #63.0.3202.45 and observed as attached in screencast.

Attached screencast for reference.

@sam.bald--Could you please check in latest beta and if you can still able to reproduce the issue , please help us with the screencast of the steps to reproduce the issue and expected result for better understanding.

Thanks!
771772.mp4
862 KB View Download

Comment 3 by yosin@chromium.org, Oct 5 2017

NextAction: 2017-10-19
Summary: NEEDS_FEEDBACK document.queryCommandState returns false after execCommand followed by clicking inside editor (was: document.queryCommandState returns false after execCommand followed by clicking inside editor)
I made sure I'm on the latest beta (62.0.3202.45) and made a screencast of the issue. Since you can't when I'm clicking, just know that whenever the formatting disappears, I've just clicked the mouse.
chrome_editor.gif
275 KB View Download
Project Member

Comment 5 by sheriffbot@chromium.org, Oct 5 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: sc00335...@techmahindra.com
Labels: -Pri-2 -Needs-Bisect hasbisect-per-revision ReleaseBlock-Stable M-62 Pri-1
Status: Untriaged (was: Unconfirmed)
Summary: document.queryCommandState returns false after execCommand followed by clicking inside editor (was: NEEDS_FEEDBACK document.queryCommandState returns false after execCommand followed by clicking inside editor)
Able to reproduce this issue on reported version 62.0.3202.38, on latest beta 62.0.3202.45 and on latest canary 63.0.3234.0 using Winodws 10 with https://dojotoolkit.org/reference-guide/1.10/dijit/Editor.html URL. Working fine in Linux and Mac

Manual Bisect Info:
================
Good Build: 62.0.3175.0 
Bad Build: 62.0.3176.0

You are probably looking for a change made after 491615 (known good), but no later than 491637 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
  https://chromium.googlesource.com/chromium/src/+log/447975f2f54a2fd264da3762b8f5470ad2d59da7..e51004f83bece58455811a9195a21001c937019a

Unable to find suspect from above changelog.[ per-revision bisect invoked changelog with many changes in it]

Could someone from Blink>Editing team take a look into this and help in assigning it to right owner.

Adding RB-Stable as this is a recent regression. Please change if not the case.
Labels: Triaged-ET
Owner: yosin@chromium.org
Status: Assigned (was: Untriaged)
yosin@, can you please look into the below changes?

https://chromium.googlesource.com/chromium/src/+/9063cb91499ef3cf13e085ae4ad27ae52e09019a
https://chromium.googlesource.com/chromium/src/+/617eb46b77426ea85bb56876eb94a054a268d16a

Thank you!
yosin@ Ping! This issue is marked as RB-Stable, could you please let us know is there any latest update available on this issue?
Thanks!

Comment 10 by yosin@chromium.org, Oct 10 2017

Components: -Blink>Editing Blink>Editing>Command
Labels: -ReleaseBlock-Stable
Owner: ----
Status: WontFix (was: Assigned)
Mark WontFix, since Chrome, Edge and Firefox behave same.

I think formatting toolbar button should represent format before cursor position or
formatting of a character will be inserted.

BTW it seems patches mentioned in #c8 are not related to this.
https://chromium.googlesource.com/chromium/src/+/9063cb91499ef3cf13e085ae4ad27ae52e09019a
- For mouse handling for selection
- When we move cursor by keyboard formatting tool buttons indicate formatting of
a character before cursor

https://chromium.googlesource.com/chromium/src/+/617eb46b77426ea85bb56876eb94a054a268d16a
- Refactoring for double-click on Windows


Actually, I did test this in Edge and Firefox and they definitely did not behave the same way as I have described. I have never encountered any sort of editor, online or desktop, that loses its formatting when clicking on the current cursor position.
The NextAction date has arrived: 2017-10-19

Sign in to add a comment