In fullscreen (f11) on windows machine, Cannot interact with omnibar on new tab (ctrl + t)
Reported by
z...@z-dxn.com,
Dec 22 2016
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Steps to reproduce the problem: 1. Open an webpage in fullscreen (f11) 2. Open a new tab (ctrl + t) 3. Attempt to type in the omnibar / address bar What is the expected behavior? Be able to search, or browse to a new page. What went wrong? No interaction with application. After reducing from full screen to regular, attempted to type and no text was rendered still, had to click out of chrome and back in to type address. Did this work before? N/A Chrome version: 55.0.2883.87 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 24.0 r0
,
Dec 22 2016
the search box displayed on the new tab page is unusable as well.
,
Dec 22 2016
>the search box displayed on the new tab page is unusable as well. Indeed! The problem is that it tries to be smart and focus omnibar when we type (BTW this is distracting and bad UX) but since omnibar is absent it silently fails.
,
Dec 22 2016
that was kinda what I was aattempting to point out, it also sucks you need to lose focus after exiting full screen, and then re select the search bar to interact with it.
,
Dec 22 2016
I think that UX specialist that decided to adopt mobile Chrome behavior designed for small screens is wrong here: on a desktop computer with a large display the focus jump is unusual and confusing. The problem however doesn't seem to be fixed easily because the focus jump is necessary to provide users with the full omnibox functionality. In order to replicate it within the bounds of the search input box it would require re-writing omnibox functionality in JavaScript which is hardly a viable option. Maybe it's possible to show the real omnibox over the search box with the same dimensions?
,
Dec 22 2016
,
Dec 23 2016
Able to reproduce this issue on windows 10,Ubuntu 14.04 using chrome stable M55-55.0.2883.87 and earlier version of chrome M33-33.0.1750.0. This is a non-regression issue and marking it as untriaged. Unable to reproduce this issue on Mac 10.12.2 Please look into the attached screencast. Thank You...
,
Jan 3 2017
Issue 677821 has been merged into this issue.
,
Jan 4 2017
Issue 678071 has been merged into this issue.
,
Sep 19 2017
,
Nov 9 2017
Issue 783076 has been merged into this issue.
,
Mar 12 2018
Issue 820725 has been merged into this issue.
,
Apr 23 2018
,
Apr 25 2018
,
May 21 2018
Issue 843432 has been merged into this issue.
,
May 25 2018
,
May 25 2018
This is heavily related to bug 243926. In that, users are complaining that they cannot enter text into the box on the NTP. In this, users are complaining they cannot get to the omnibox to enter text. If we fix either (though likely both have the same fix), all users will be happier.
,
May 30 2018
,
Jun 18 2018
Issue 853113 has been merged into this issue.
,
Aug 7
Issue 871141 has been merged into this issue.
,
Sep 18
,
Sep 20
I am encountering this on Mac OS X, but it is inconsistent. It just happened again, but now I cannot replicate it.
,
Sep 24
Issue 888255 has been merged into this issue.
,
Sep 28
,
Nov 7
,
Nov 7
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 Deleted