Issue metadata
Sign in to add a comment
|
Maximized MD windows have space above tabstrip on scale factor 2 |
||||||||||||||||||||||
Issue descriptionVersion: 51.0.2692.2 OS: Win10 What steps will reproduce the problem? (1) Enable chrome://flags/#top-chrome-md "Material design in the browser's top chrome" (2) Try to click and use the most top pixels of Chrome window when it is maximized, for selecting tabs What is the expected output? It should be clickable, in fact this is a popular use demand AFAICT, see my question here about workaround for having same thing on Opera http://superuser.com/q/509354 and another one http://superuser.com/q/657998 What do you see instead? It isn't, instead mouse cursor icon turns into a useless two way array. Maybe the is HiDPI only, but anyway not available on when flag is turned off.
,
Mar 29 2016
,
Mar 29 2016
What is your native scale factor? I can't reproduce this at 1x; I can reproduce when forcing scale 2 on my 1x device, but I don't have a native-2x device to test with to see if the problem occurs there or is specific to the forced-scale case. I also get the exact same results with or without MD enabled, so AFAICT this has nothing to do with MD. Is that what you see?
,
Mar 29 2016
My "devicePixelRatio" is 2 (200%). I can not repro the issue without MD, see the attachment where cursor is on hi top of screen but is not turned into two way arrow icon, more importantly I can click not selected tabs also without MD which is important perhaps I'd guess for touchpad users
,
Mar 29 2016
Can you post screenshots of the full window in these cases instead of these super-zoomed-in ones?
,
Mar 29 2016
Hmm. Very strange. There's definitely a difference in how we calculate the top resize area. When forcing scale factor 2 locally, I get weird layout because we still use the system-provided border sizes and the like, which aren't scaled up as they would be on a real 200% device. But I can see that for non-MD, the client area goes up noticeably above the tabstrip (on my screen, there's just 2 px of "resize border" atop the screen), whereas for MD the "resize" area starts almost immediately above the tabstrip. So hopefully even without a 200% device I'll be able to try to fix this. This is definitely not an issue we want to regress.
,
Mar 30 2016
,
May 3 2016
Can we get an update on this Beta blocker issue? We are expecting M-52 branch in 3rd or 4th week of May.
,
May 3 2016
No work has been done here since I'm mostly out of commission. This is beta-blocking for whatever release ships MD on Windows, but it's not currently clear whether we're still going to try for M52 for that.
,
May 4 2016
,
May 4 2016
,
May 8 2016
,
May 18 2016
,
May 25 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9e91a05128c2cfea44dac34dee003f7919bf74d3 commit 9e91a05128c2cfea44dac34dee003f7919bf74d3 Author: bsep <bsep@chromium.org> Date: Wed May 25 19:14:10 2016 Floor rather than round the top border thickness to keep it in line with hittests, which are floored. Also use forced scale factor to calculate this value, so maximized windows behave better in that mode. BUG= 598469 Review-Url: https://codereview.chromium.org/2011723002 Cr-Commit-Position: refs/heads/master@{#395955} [modify] https://crrev.com/9e91a05128c2cfea44dac34dee003f7919bf74d3/chrome/browser/ui/views/frame/glass_browser_frame_view.cc
,
May 25 2016
,
Sep 28 2016
[Auto-generated comment by a script] We noticed that this issue is targeted for M-52; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-52 label, otherwise remove Merge-TBD label. Thanks.
,
Sep 28 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ebra...@gnu.org
, Mar 28 20161.4 KB
1.4 KB View Download