Textbox focus seems incomplete on long-press |
||||
Issue descriptionCurrently we send a mousedown on a long-press as a hack to make focus work. W/o the mousedown, a long-press sets the focus to a textbox but doesn't bring the cursor there. It seems that the cursor is set in the default handler for mousedown which is clearly wrong since canceling the mousedown exposes the bug. Steps to reproduce: 0. Open Chrome on a touch device or with touch emulation, goto http://output.jsbin.com/raqubal/quiet 1. Long-press in the space between word1 and word2. 2. Long-press in the space between word3 and word4. Expected behavior: The second textbox should get the cursor on Step 2, like the first textbox in Step 1. Actual behavior: The second textbox doesn't get the cursor on Step 2. Note that long-press on a word (instead of on spaces) triggers text selection, which seems to work perfectly.
,
Nov 1 2016
,
Nov 1 2016
Seems like a good bug for Pedro's backlog. Either the logic should be added to the long-press handler or some common point for the logic should be found.
,
Nov 7 2016
Should long press not cause a mousedown at all? Or should it do the mousedown and cause the cursor to appear?
,
Nov 8 2016
Hmm, yeah, on further thought, I'm not sure if there's a bug here at all. It's appropriate for mousedown (as opposed to mouseclick) to adjust cursor position because on a desktop, mousedown can be the beginning of a selection drag. And if we do send a mousedown (as a "hack" or otherwise), there's no need to put any cursor-moving logic elsewhere. mustaq@, what's your context for filing this bug? Is it that you're trying to remove the mouse events for longpress and this is a blocker for that removal?
,
Nov 8 2016
Yes, I tried to remove mousedown on long press to mimic mobile Safari ( crbug.com/579564 ) while working on a related cleanup ( crbug.com/629876 ). After finding the missing-cursor-in-textbox bug, we kept the mousedown as is. Later on, we found another sideeffect of the mousedown which is clearly bad: canceling the mousedown affects the cursor appearance. So the best solution here seems to be skipping the mousedown firing and setting the cursor on long-press unconditionally.
,
Nov 8 2016
Those bugs are both marked fixed, should one of them be reopened and marked as blocking on this bug?
,
Nov 8 2016
,
Nov 21 2016
|
||||
►
Sign in to add a comment |
||||
Comment 1 by mustaq@chromium.org
, Nov 1 2016