SelectionEnd in TextArea with newlines seems wrong when using Ctrl-A
Reported by
alban.le...@gmail.com,
Sep 10
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36 Steps to reproduce the problem: See https://jsfiddle.net/b8ee0gnu/1190/ 1. Type 'a' 2. Type <Shift-Return> 3. Type <Ctrl-A> The selection after the keyup event is start=0, end=3 What is the expected behavior? The expected behavior would be to get a selection equal to start=0, end=2 What went wrong? The selection has the wrong value after using Ctrl-A when the Textarea has newlines Did this work before? No Chrome version: 69.0.3497.81 Channel: stable OS Version: 10.0 Flash Version: Flash disabled
,
Sep 11
alban.lefebvre@ Thanks for the issue. Able to reproduce the issue on Windows 10, Mac OS 10.13.3 and Ubuntu 17.10 on the latest Stable 69.0.3497.81 and the latest Canary 71.0.3548.0. Cannot observe the correct keyup event values equal to start=0, end=2 after following the steps mentioned above. Attached is the screen shot for reference. This is a Non-Regression issue as this is observed from M-60 chrome builds. Hence marking this as Untriaged for further updates from Dev. Thanks..
,
Sep 11
,
Sep 26
Route to Blink>Forms>Textarea since it seems this is an issue of calculating HTMLTextFromElement's selection offset from FrameSelection.
,
Sep 26
It seems "PlaceholderBreakElement" is included in the selection, and counted as 1. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by krajshree@chromium.org
, Sep 11