Omnibox does not hide on Android sometimes for "Request desktop site"
Reported by
oughtimp...@gmail.com,
Jul 6 2017
|
|||||
Issue descriptionPlease see description at the bottom. Android. >> Chrome Version: << 59.0.3071.125 (Official Build) (32-bit) >> What steps will reproduce the problem? << (1)Open Chrome on Android (2)Select Desktop Version (3)Flip Device into landscape mode >> What is the expected result? << The omnibox should hide itself automatically when you select it as a chrome setting. >> What happens instead? << Some websites were written so that they eventually go fullscreen, while others (such as console.cloud.google.com along with the popup cloud shell) never go fullscreen because the page scrollable area does not scroll but inner page areas have their own scroll areas... >> Please provide any additional information below. Attach a screenshot if possible. << These desktop sites and others, like script.google.comm, work perfectly fine on mobile chrome apart from not auto hiding the omnibox... It seems as though the reason is just not anticipating mobile devices wanting to use the desktop versions of these sites. The solution would seem to be to give end users that optional functionality instead of expecting every desktop web site to include the update or be rewritten for this use case... I think this would be worth your time given the potential future users looking for desktop versions on mobile, future users potentially including developers. I'm going to attempt to have my mobile (along with a wireless keyboard, mouse, and goggle headset) as my primary device for developer things using google's cloud platform tools (like cloud shell) via chrome.
,
Jul 6 2017
,
Jul 21 2017
I can reproduce the problematic behavior and agree it should be improved.
,
Jul 22 2017
I've attached a screenshot of what console.cloud.google.com looks like on chrome mobile when you open cloud shell... notice just how much screen real estate is going to things other than the actual web page...
,
Jul 22 2017
CC tedchoc@ to see if he wants to convince someone to fix this
,
Jul 22 2017
Lol, I mean... for the love of all that is holy, it's just so close to being that much more amazing... imagine users of the future (including developers) using those VR headsets not to play VR games but to browse chrome with wireless keyboards and wireless mouses hooked up to their android device...
,
Jul 26 2017
Sadly, I believe this is unactionable. Chrome doesn't want to get into the business of guessing when a site wants to be able to scroll off the omnibox. We provide the mechanisms for the site to build it, but if we guess wrong then we are getting into a bad security state where the omnibox could be scrolled off but never retrieved.
,
Jul 26 2017
Note: as a workaround, you should be able to hide the omnibox by pinch-zooming in, scrolling down, and then pinch-zooming back out.
,
Jul 27 2017
I'm not sure how to quote someone in a response, but Chrome would not be getting into the guessing game of picking when a website would be better served on mobile by hiding the omnibox if they just had an option in the default settings that each user could toggle so that the default behavior of chrome would go from its current behavior of sometimes hiding and sometimes not to always hiding and temporarily viewable if you swipe down from the top or something... This is a really simple thing and it's just irrational to expect all of the desktop sites to modify themselves for optimal experience on a mobile still accessing the desktop version... this is something Chrome needs to do... Side note, chrome also needs to have a "request desktop site first" setting so there isnt a need to constantly load every web page you visit twice, first as the mobile version and second as the desktop version.
,
Jul 27 2017
that workaround is hiding the omnibox but then seems to be moving the bottom of the page upward so that the same amount of screen real estate is being wasted, just below the actual page instead of above it... attached a screenshot of console.cloud.google.com |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by krajshree@chromium.org
, Jul 6 2017