Insertion handle not dismissed after intenting out of browser |
||||||
Issue descriptionFrom b/32012409, but this is a reduced test case. * Load https://output.jsbin.com/hekuhohumi, in chrome or webview shell. important bits of html: <div contenteditable="true"> this is edtiable <div contenteditable="false"> <a href="https://play.google.com">not editable link to google</a> </div> this is editable too </div> * Click on first line, which is editable. Blinking cursor and handle appears. * Very carefully, click on the link, which should intent out to the play store app. * Click back to go back to chrome or webview shell Now the focused element is the link, which is not editable, so the blinking cursor disappears. However, the cursor handle is still here, below the first line. This is a pretty edge case scenario. Not very high priority. But it is a bug. Would be good to figure out whether blink did not signal that editing has stopped, or if it's something wrong in the upper layer about dismissing the handle.
,
Dec 23 2016
From the surface, |SelectionPopupController| is not getting the event INSERTION_HANDLE_CLEARED. This is not a regression. I can see it repro'ed in 52.0.2705. Will try bisecting.
,
Jan 3 2017
+amaralp This bug dates all the way back to 49. Cc'ing amaralp@ who may be able to shed some light.
,
Jan 3 2017
I think the problem was there for a while, but in most cases clicking through a link overrides the selection so did not surface so far. Link overriding logic is not just for Android, but desktop external handlers (such as mailto://) may have the same problem. I wonder if it is possible to keep the selection when you come back to Chrome instead of dismissing handles.
,
Jan 3 2017
> I wonder if it is possible to keep the selection when you come back to Chrome instead of dismissing handles. In this case it's the insertion handle, not selection handles. Not sure what the expected behavior of selection handle should be in this case though. If selection and insertion happen to go through the same code path, then this might be tricky..
,
Jan 9 2017
,
Jan 31 2017
I'm not focusing on this at this moment. Made it available for anyone
,
Feb 15 2018
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. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 19 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by jinsuk...@chromium.org
, Dec 23 2016