Keyboard is not dismissed on opening a webpage in chrome through safari keeping context menu on top. |
||||||||
Issue descriptionApp Version: 58.0.3029.39 dev iOS Version: 10.2.1 Device: iPhone only URL: Steps to reproduce: 1. Launch chrome 2. Long press on Most Popular site icon for context menu to display 3. Tap on Home button. 4. Go to Safari browser --> Open URL : googlechrome://cnn.com or pdf file and tap on on Open in chrome dev Observed results: 1. Notice that the keyboard pop ups automatically. 2. Cancel button in Omnibox is missing Expected results: Keyboard should be dismissed when the URL is opened in chrome browser Number of times you were able to reproduce: 5/5 Bug reproducible after clean install: Yes Bug reproducible after clearing cache and cookies: Yes Bug reproducible on Chrome Mobile on Android: Not tested Bug reproducible on Safari/Firefox: Firefox: NA, Safari: NA Bug reproducible on current stable build (App Version, iOS Version): Yes on M57.0.2987.100 Bug reproducible on the current beta channel build (App Version, iOS Version): Yes Link to video/image: https://drive.google.com/a/google.com/file/d/0Bz2uwV55gGwDbDVTU3VFQkhXcUk/view?usp=sharing
,
Mar 29 2017
+justincohen@ for opinion on NTP. This is caused by the fact that we try to cancel the editing mode of the omnibox before dismissing all the dialogs present on the page. I don't think moving the cancelling of the editing mode is totally safe as a lot of things are getting cancelled between the two. We can either cancel the editing mode twice (one before dismissing the dialogs, one after) or prevent the NTP from showing the context menu while editing. WDYT?
,
Mar 30 2017
Why does "cancel the editing mode of the omnibox before dismissing all the dialogs present on the page" fail?
,
Mar 30 2017
Because the omnibox is not selected anymore, but when the action sheet is dismissed, the omnibox regain focus. Do you think it should cancel the editing even if something is presented?
,
Apr 3 2017
Why does stopping the context menu restore focus to the omnibox?
,
Apr 4 2017
You mean in general or in this case? In general I guess it is the expected behavior: you were focusing something, an alert shows up, taking the focus. You dismiss the alert, you are back to the element you were focusing.
,
Apr 4 2017
Can the 'previously focused item' change while the alert is shown?
,
Apr 4 2017
I did not find a way to do this. I think the easiest way to fix this is to remove the focus from the omnibox when the alert is shown. What do you think?
,
Apr 4 2017
Removing the focus from the omnibox will shift the most visited icons down. I'm not a big fan of moving a bunch of the UI unexpectedly during a long press. rohitrao@ what do you think?
,
May 5 2017
rohit: ping
,
May 5 2017
It seems to be working fine in Canary for me (keyboard doesn't popup).
,
May 5 2017
,
May 9 2017
Mardini, I was able to repo in Canary :) If doing what gambard@ mentioned in #8 fixes things, could we mitigate the problem mentioned in #9 by simply not scrolling the view (like normal) when the omnibox loses focus via an alert? It is possible, after all, to scroll the NTP and get the same layout achieved by focusing the omnibox.
,
May 12 2017
I think #13 behavior would be fine.
,
Jun 29 2017
justin, mardini, any opinion?
,
Jun 29 2017
how bad does cancelling twice look? does it preserve current functionality?
,
Jul 3 2017
I don't understand "cancelling twice". Can you explain?
,
Jul 3 2017
I'm find with the behaviour proposed in #13.
,
Jul 5 2017
gambard@ in comment 2 you suggested: "We can either cancel the editing mode twice (one before dismissing the dialogs, one after) or... I'm curious if that solution preserves the current functionality.
,
Feb 19 2018
,
Sep 27
I cannot reproduce this with M72 Chromium -- can you retest with post refresh builds?
,
Oct 11
This issue is still reproducible with chrome beta version 70.0.3538.58 with UIRefresh. Checked on iPhone 8 plus with iOS 11.4.1 and iPad Air with iOS 12.1 beta 2 |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by edchin@chromium.org
, Mar 27 2017Labels: M-58
Owner: gambard@chromium.org
Status: Assigned (was: Untriaged)