Chrome bleeding into taskbar
Reported by
dapal...@gmail.com,
Sep 14
|
|||||
Issue description
Chrome Version : 68.0.3440.106 & 69.0.x
OS Version: 10.0
URLs (if applicable) : -
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari: -
Firefox: OK
IE/Edge: OK
What steps will reproduce the problem?
1.Move taskbar to the top position.
2.Set taskbar opacity to 0% using TranslucentTB.
3.Make chrome fullscreen.
What is the expected result?
Chrome's frame staying outside of the taskbar.
What happens instead of that?
The top of chrome's frame sticks out into the taskbar.
Please provide any additional information below. Attach a screenshot if
possible.
https://i.imgur.com/VNikh3r.png - chrome fullscreen
https://i.imgur.com/WMsSzFO.png - firefox fullscreen
https://i.imgur.com/gnYsx0T.png - edge fullscreen
https://github.com/TranslucentTB/TranslucentTB - Github to software that allows user to change taskbar to be completely transparent. I use start10 but it's a payed piece of software.
UserAgentString: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
,
Sep 14
,
Sep 16
,
Sep 17
You don't actually need to make the taskbar more transparent, the extra space is visible with native settings, it's just not as apparent.
,
Sep 17
Looks like this was introduced in https://codereview.chromium.org/2381283003. The relevant context from there and BrowserDesktopWindowTreeHostWin::GetClientAreaInsets() is: - we need zero non-client area on top or Windows will draw a native titlebar - we don't utilize client area transparency anywhere else, so by not using it here we can turn it off, giving us a pretty substantial win on power consumption We could recheck those assertions, but it seems to me that as long as both of those things are still true we're doing the right thing here. Maybe we can talk to MS about fixing the first issue?
,
Sep 17
I doubt Microsoft can fix the non-client top area behavior without breaking backwards compatibility. It's possible there's no way to fix this given the tradeoffs, but I would guess we can put in a special case for top toolbar somewhere. Maybe we need to return 0 in GlassBrowserFrameView::FrameTopBorderThicknessPx?
,
Sep 17
My feeling is that the top toolbar special case would be to turn on transparency and take the power hit only for maximized windows with a top toolbar. A FrameTopBorderThicknessPx of 0 moves the top of the tabstrip up to the top of the client area (see attached).
,
Nov 20
***Mass UI Triage*** As per comments.
,
Jan 11
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by meh...@chromium.org
, Sep 14Labels: -Pri-3 Pri-2