Issue metadata
Sign in to add a comment
|
Pressing return while in a content editable might jump out of the content editable |
||||||||||||||||||||||||||
Issue descriptionOS X 10.11. Chrome Canary 51.0.2673.0. VoiceOver on. 1. Focus a content editable, e.g. the e-mail body field in Gmail's compose window. 2. Type something and press return. 3. Notice that the focus may jump to a completely different part of the page.
,
Mar 13 2016
,
Mar 13 2016
,
Apr 8 2016
,
Apr 11 2016
Unable to reproduce the issue on MacBook Pro Retina 10.11.4 chrome version 51.0.2673.0 and canary 51.0.2704.2 - With voice over on typing in the e-mail body field in Gmail's compose window and pressing enter the focus goes to the next line as expected. Please find the screencast Could you please let me know if i am missing something here in reproducing the issue. A screencast would be helpful in debugging.
,
Apr 11 2016
Another thing I'm wondering is whether there's an extension that causes this.
,
Apr 19 2016
nektar@, Could you please recheck the same in a new profile where there are no extensions/apps and update the thread.
,
May 23 2016
nektar@, Gentle ping!!! Could you please respond as per comment #7
,
May 23 2016
We have determined a possible cause for this issue. Chat notifications in Gmail might make the VoiceOver cursor to jump out of the content editable where the user is composing an e-mail. We need to wait for a response from the Gmail Team to see if this is something that needs to be handled on Chrome's side.
,
May 24 2016
As per comment #9 removing the Needs-Bisect label for now. Please feel free to add it back if required.
,
Sep 7 2016
I asked around and the issue doesn't seem to occur any more. Marking fixed for now.
,
Sep 7 2016
My bad. Victor says that the issue still occurs, mostly if not exclusively in Gmail when composing an email. It doesn't happen with ChromeVox. Only with Voiceover.
,
Dec 2 2016
I figured out the cause of the issue. It's in Blink.
AXLayoutObject::selection() {
...
focus = selection.endPosition().toParentAnchored();
...
}
In the case of a letter, the end position of the selection (i.e. where the cursor is) would be inside an inline text box. So, the parent anchored position would be the equivalent offset inside the static text node that houses the inline text box.
However, in the case of a <br> element, the parent anchored position lands inside an editable div that houses the <br> element. I don't know why a div element wraps each <br> element, but I verified that if I return the <br> element itself whenever the focus lands on a new line, then the issue goes away.
,
Dec 2 2016
|
|||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||
Comment 1 by nek...@chromium.org
, Mar 10 2016