Issue metadata
Sign in to add a comment
|
Chrome window minimum width is now absurdly high
Reported by
k...@luminance.org,
Aug 17
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0 Steps to reproduce the problem: 1. Visit a http website in a foreign language 2. Set zoom to 75% 3. Observe 'google translate' and 'zoom' and 'not secure' indicators all in the address bar 4. Shrink the window as far as you can horizontally 5. Open https://google.com/ 6. Set zoom to 100% 7. Shrink the window as far as you can horizontally What is the expected behavior? The minimum size for the first scenario (a japanese webpage w/zoom set, in my specific case) used to be considerably smaller before the new UI theme, and my extension icons were visible at much smaller sizes. The minimum should be closer to what it is for the Google homepage, if not smaller than that. What went wrong? Changing tabs causes the browser to recompute what the minimum size of a tab should be, and as soon as you tap the right edge to try to resize, it enforces the new minimum size. The minimum sizes are now very big for common scenarios. Now I'm stuck with a very wide window filled with blank space, and if I zoom out to make the content smaller *the window must become bigger*. If I want to see any of my extensions the window must become bigger still. The cause of this seems to be that the minimum size is dynamically computed based on all the goop currently visible in the toolbar. The new theme increased margins and moved new things into the address bar - like the profile icon that used to be in the title bar, and that absurd zoom icon, using up space to draw my attention to something that is already in the hamburger menu. I can't get rid of either of those icons so they are just eating up horizontal space on my desktop now, forever, for each Chrome window I want to have open that would otherwise be small. Did this work before? Yes The old theme Chrome version: Version 70.0.3524.0 (Official Build) canary (64-bit) Channel: canary OS Version: 10.0 Flash Version: Funnily enough, secure origins like 'chrome://settings' have a larger minimum width because of that 'Chrome' origin indicator. If I switch to a tab with a crowded toolbar while the window is small, everything compacts the way it should, so there's not really a good reason for forbidding me from shrinking the window. The 'not secure' indicator stays visible at the cost of the address (fine, I guess?), and the translate and bookmark and profile icons all stay visible, because apparently those are important - seems to work fine even if I disagree with it.
,
Aug 19
,
Aug 20
kg@ Thanks for the issue... Tested this issue on reported chrome 70.0.3524.0 and latest chrome 70.0.3527.0 using windows 10. Attaching screen-cast for reference. Steps: ----- 1. Launched reported chrome 2. Navigated to " https://google.com/ " 3. Navigated to chrome://settings >> changed zoom level 100% to 75%, as per the screen-cast As we are able to see the chrome browser window as per comment #1 @Reporter: Could you please check the attached screen cast and please let us know if anything missed from our end. Thanks..!
,
Aug 21
Seems to be working as intended, but take a look.
,
Aug 21
I can understand this being intended but it's a major usability regression. In many cases the minimum size for a window used to be half what it is now - if you have lots of tall narrow content open on a regular basis you're losing a lot of screen space to this.
,
Oct 1
A related bug in this change: If the minimum window size is very high and causes extension toolbar buttons to be hidden, switching to the 'new tab' page will suddenly reveal the toolbar buttons, and they will remain there even if you switch to a tab where the buttons should be invisible. So this creates a confusing random behavior where your extension buttons are never in the same place
,
Nov 19
*** UI Mass Triage *** Closing, since there is no update since the past few weeks. If you feel this issue should still be addressed, feel free to reopen it or to file a new issue.
,
Nov 19
Issue still not addressed.
,
Nov 21
This is also a problem for automated testing - tests that use a smaller window size breaks when updating the browser.
,
Nov 26
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by k...@luminance.org
, Aug 17591 KB
591 KB View Download