New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 41 users

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Blocking:
issue 8606



Sign in to add a comment
link

Issue 361720: Fullscreen chrome cut off on the edges with 64-bit chrome.

Reported by zturner@chromium.org, Apr 9 2014 Project Member

Issue description

Version: 36.0.1932.2 (Official Build 262602) canary
OS: Windows 8.1

What steps will reproduce the problem?
1. Open Chrome
2. Maximize the Browser window

It appears that a few pixels are cut off on each edge of the browser window.  This is most noticeable on the top edge and the right edge.  On the top edge for example, the system menu (minimize, maximize, restore buttons) are visibly cut off at the top, and the same can be said for the profile bubble icon as well as the "curved" top of the tab widget.

I suspect something related to the compositor and/or gpu process.  I saw this same issue the last time we had a 64-bit canary, so this is probably somehow related to 64-bit.

Assigning to jbauman for now for triage, but if this is not gpu-related, feel free to re-assign.
 

Comment 1 by jbau...@chromium.org, Apr 9 2014

This happens with --disable-gpu as well, so it's not GPU-related. It may still be compositor-related, though.

Comment 2 by zturner@chromium.org, Apr 9 2014

Cc: lafo...@chromium.org dxie@chromium.org

Comment 3 by zturner@chromium.org, Apr 9 2014

It looks like we might be rendering into a buffer which is a few pixels too large, and then clipping it to the correct screen size and drawing that into the window.  I took this screenshot while hovering over a URL so that the url status bubble appears, and you can see that the URL status bubble extends below the top of the taskbar by a few pixels, indicating that something thinks the browser is a few pixels larger than it should be.
Canary2.png
83.5 KB View Download

Comment 4 by raphael...@gmail.com, Apr 9 2014

I confirm this happening on 36.0.1932.2 @ Win7 Pro x64 also.
Both what OP said and also #3.

Comment 5 by jbau...@chromium.org, Apr 9 2014

Cc: jbau...@chromium.org
Owner: zturner@chromium.org
On my machine, 32-bit chrome has DesktopWindowTreeHostWin::HandleClientSizeChanged called with a size of 2560x1568, while on 64-bit chrome it's called with a size of 2568x1572, so for some reason the win32 client area dimensions are probably incorrect.

Comment 6 by jbau...@chromium.org, Apr 9 2014

Also, looks like delegate_->GetClientAreaInsets is giving 0,4,4,4 on 64-bit and 0,8,8,8 on 32-bit.

Comment 7 by jsc...@chromium.org, Apr 15 2014

 Issue 342912  has been merged into this issue.

Comment 8 by jsc...@chromium.org, Apr 15 2014

Blocking: chromium:8606

Comment 9 by pjm...@gmail.com, Apr 18 2014

This is also happening here, Windows 7 64 bits, all 64 bits builds I tested have this problem, 32 bits are working fine.

Comment 10 by jbau...@chromium.org, Apr 18 2014

Owner: jbau...@chromium.org
Status: Started
Actually, I think I know how to fix this.

Comment 11 by bugdroid1@chromium.org, Apr 22 2014

Project Member
------------------------------------------------------------------
r265329 | jbauman@chromium.org | 2014-04-22T19:34:06.835166Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/views/frame/browser_desktop_window_tree_host_win.cc?r1=265329&r2=265328&pathrev=265329
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/views/win/hwnd_message_handler.cc?r1=265329&r2=265328&pathrev=265329

Add SM_CXSIZEFRAME and SM_CXPADDEDBORDER metrics to get window border size.

Vista added the SM_CXPADDEDBORDER system metric which needs to be included
in the border size. The previous code happened to work with 32-bit Chrome
because Windows added the padding into SM_CXSIZEFRAME (and set the padding to 0)
for backwards compatibility, but with 64-bit that changed.
GetSystemMetrics(SM_CXPADDEDBORDER) should always return 0 on XP.

BUG= 361720 

Review URL: https://codereview.chromium.org/243173005
-----------------------------------------------------------------

Comment 12 by jbau...@chromium.org, Apr 22 2014

Status: Fixed

Comment 13 by solitude...@gmail.com, Apr 23 2014

It looks better, but for me it seems the top is still cut off a few pixels, see attachment. Using Windows 8.1 Update 1 Pro x64 with Chromium 265382 x64.
ChromiumTop.png
191 KB View Download

Comment 14 by manoranj...@chromium.org, Apr 24 2014

Labels: Needs-Feedback
Tested this fix on Latest 64 bit chrome#36.0.1954.0 (Official Build 265607) m on Win7 - Still able to reproduce this.

PS: Attached both 32 & 64 bit chrome screenshots for your reference.

Thank you.
36.0.1954.0_32bit.JPG
29.9 KB View Download
36.0.1954.0_64bit.JPG
37.9 KB View Download

Comment 15 by jbau...@chromium.org, Apr 24 2014

Status: Started
Looks like I fixed the left, right and bottom, but the top is still broken. I've tried to move the client area down by SM_CXPADDEDBORDER (==4) pixels, but that hits the bug mentioned at https://code.google.com/p/chromium/codesearch#chromium/src/ui/views/win/hwnd_message_handler.cc&q=DwmDefWindowProc&sq=package:chromium&l=1676 where the caption buttons stop working. I'm not sure if there's another way to get a similar result - maybe we could somehow keep the client area the same but move the actual rendering(/other events) down by the correct distance. Or maybe it's possible to change the window position itself when it's maximized.

Comment 16 by manoranj...@chromium.org, Apr 25 2014

Labels: -Needs-Feedback

Comment 17 by scottmg@chromium.org, May 1 2014

Cc: zturner@chromium.org
 Issue 369120  has been merged into this issue.

Comment 18 by scottmg@chromium.org, May 1 2014

 Issue 369120  has been merged into this issue.

Comment 19 by jbau...@chromium.org, May 8 2014

Owner: ben@chromium.org
The only way I can think of to fix the top border is to change the bounds of the aura root window to move it down 4 pixels, then deal with all the changes in input events and so on, but that seems pretty ugly. Maybe ben@ would have some better ideas.

Comment 20 by jsc...@chromium.org, Jun 3 2014

FWIW it doesn't get clipped with the --disable-dwm-composition switch.

Comment 21 by zturner@google.com, Jun 3 2014

Maybe play with the values we pass to DwmExtendFrameIntoClientArea and see if twiddling them makes a difference.

Comment 22 by jsc...@chromium.org, Jun 3 2014

 Issue 287151  has been merged into this issue.

Comment 23 by martinzu...@gmail.com, Jun 3 2014

I can confirm, on Canary, top 4 pixels are cut off.
Please see how it looks on current Stable vs. Canary on Win 8.1:
chrome_tab.png
15.3 KB View Download

Comment 24 by wfh@chromium.org, Jun 3 2014

Labels: ReleaseBlock-Beta M-37

Comment 25 by wfh@chromium.org, Jun 3 2014

 Issue 380187  has been merged into this issue.

Comment 26 by kymetro9...@gmail.com, Jun 3 2014

Seems this only affects the classic theme. Change to any other theme and the window maximizes properly.

Comment 27 by wfh@chromium.org, Jun 3 2014

 Issue 380196  has been merged into this issue.

Comment 28 by scottmg@chromium.org, Jun 3 2014

Cc: ben@chromium.org
Owner: scottmg@chromium.org
I'll take a look.

Comment 29 by humu...@gmail.com, Jun 3 2014

Can confirm the issue on the dev channel. Only classic Theme is affected. Switched to Grayscale theme in the meantime

Comment 30 by scottmg@chromium.org, Jun 3 2014

Best Fix Ever or Bestest Fix Ever? https://codereview.chromium.org/311953003

Comment 31 by martinzu...@gmail.com, Jun 4 2014

Current Canary (37.0.2029.0) is FIXED. :)
Thanks...

Comment 32 by stan...@gmail.com, Jun 4 2014

Almost Scott, almost! :) See screenshot, text in the new profile dropdown needs to go down a little now. (The text rendering of that looks horrible btw)
2014-06-04_12-13-04.png
4.3 KB View Download

Comment 33 by kymetro9...@gmail.com, Jun 4 2014

Still broken for me using Classic theme. Tabs cut off as before. See screenshot.

Using latest version 37.0.2029 on Windows 8.1 64 bit.
Fullscreen capture 642014 81047 AM.bmp
5.9 MB Download

Comment 34 by toni.m.k...@gmail.com, Jun 4 2014

Still broken, using 37.0.2029.0 (274661) x64 and Windows 7 x64 SP1.

Comment 35 by wfh@chromium.org, Jun 4 2014

This change hasn't landed quite yet - so you shouldn't see it fixed... yet!

Comment 36 by toni.m.k...@gmail.com, Jun 4 2014

Thanks for your fast reply, I keep in touch. :)

Comment 37 by bugdroid1@chromium.org, Jun 4 2014

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/68c88b0f0a645ac90365686f82edb5cb5580c2e9

commit 68c88b0f0a645ac90365686f82edb5cb5580c2e9
Author: scottmg@chromium.org <scottmg@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Wed Jun 04 17:16:04 2014

Set /SUBSYSTEM down to 5.02 on x64 to more closely match x86

This makes us get XP/Server 2003 compatible metrics for window
sizes and so indirectly fixes pixels being cut off at the top
of the window.

(Server 2003 compatible metrics make us match x86 behaviour, and
since we need to maintain XP subsystem there indefinitely, I can
sort of rationalize it on that basis.)

R=jschuh@chromium.org, wfh@chromium.org
BUG= 361720 

Review URL: https://codereview.chromium.org/311953003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@274853 0039d316-1c4b-4281-b951-d872f2087c98

Comment 38 by bugdroid1@chromium.org, Jun 4 2014

Project Member
------------------------------------------------------------------
r274853 | scottmg@chromium.org | 2014-06-04T17:16:04.412720Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?r1=274853&r2=274852&pathrev=274853

Set /SUBSYSTEM down to 5.02 on x64 to more closely match x86

This makes us get XP/Server 2003 compatible metrics for window
sizes and so indirectly fixes pixels being cut off at the top
of the window.

(Server 2003 compatible metrics make us match x86 behaviour, and
since we need to maintain XP subsystem there indefinitely, I can
sort of rationalize it on that basis.)

R=jschuh@chromium.org, wfh@chromium.org
BUG= 361720 

Review URL: https://codereview.chromium.org/311953003
-----------------------------------------------------------------

Comment 39 by martinzu...@gmail.com, Jun 4 2014

This is really weird, current Canary (37.0.2030.0) is broken again for me (cut off top of tabs). Canary from earlier today (37.0.2029.0) was okay. Situation is for me now the same as I posted in #23.
I really dont get it...

Comment 40 by jsc...@chromium.org, Jun 4 2014

Anyone seeing a temporary fix was probably briefly switched between win64 and win32. There was an issue with the update server where it was temporarily serving the win32 installs to users already on the win64 channel. However, that should now be fixed, and those users are now being updated back to win64. the actual fix for this bug should ship in tomorrow's canary.

Comment 41 by wfh@chromium.org, Jun 4 2014

 Issue 380344  has been merged into this issue.

Comment 42 by wfh@chromium.org, Jun 4 2014

 Issue 380348  has been merged into this issue.

Comment 43 by wfh@chromium.org, Jun 4 2014

 Issue 380902  has been merged into this issue.

Comment 44 Deleted

Comment 45 Deleted

Comment 46 by bugdroid1@chromium.org, Jun 5 2014

Project Member
------------------------------------------------------------------
r275261 | jbauman@chromium.org | 2014-06-05T22:24:19.093969Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/views/frame/browser_desktop_window_tree_host_win.cc?r1=275261&r2=275260&pathrev=275261
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/views/win/hwnd_message_handler.cc?r1=275261&r2=275260&pathrev=275261

Revert 265329 "Add SM_CXSIZEFRAME and SM_CXPADDEDBORDER metrics ..."

This sometimes causes a few issues with multimonitor setups. Also, r274853 fixes it more thoroughly.

> Add SM_CXSIZEFRAME and SM_CXPADDEDBORDER metrics to get window border size.
> 
> Vista added the SM_CXPADDEDBORDER system metric which needs to be included
> in the border size. The previous code happened to work with 32-bit Chrome
> because Windows added the padding into SM_CXSIZEFRAME (and set the padding to 0)
> for backwards compatibility, but with 64-bit that changed.
> GetSystemMetrics(SM_CXPADDEDBORDER) should always return 0 on XP.
> 
> BUG= 361720 
> 
> Review URL: https://codereview.chromium.org/243173005

BUG= 361720 , 379321 
TBR=jbauman@chromium.org

Review URL: https://codereview.chromium.org/321463003
-----------------------------------------------------------------

Comment 47 by bugdroid1@chromium.org, Jun 5 2014

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7ed9d7566dbb78bb4122aa66e0c9cf883027652d

commit 7ed9d7566dbb78bb4122aa66e0c9cf883027652d
Author: jbauman@chromium.org <jbauman@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Thu Jun 05 22:24:19 2014

Revert 265329 "Add SM_CXSIZEFRAME and SM_CXPADDEDBORDER metrics ..."

This sometimes causes a few issues with multimonitor setups. Also, r274853 fixes it more thoroughly.

> Add SM_CXSIZEFRAME and SM_CXPADDEDBORDER metrics to get window border size.
> 
> Vista added the SM_CXPADDEDBORDER system metric which needs to be included
> in the border size. The previous code happened to work with 32-bit Chrome
> because Windows added the padding into SM_CXSIZEFRAME (and set the padding to 0)
> for backwards compatibility, but with 64-bit that changed.
> GetSystemMetrics(SM_CXPADDEDBORDER) should always return 0 on XP.
> 
> BUG= 361720 
> 
> Review URL: https://codereview.chromium.org/243173005

BUG= 361720 , 379321 
TBR=jbauman@chromium.org

Review URL: https://codereview.chromium.org/321463003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@275261 0039d316-1c4b-4281-b951-d872f2087c98

Comment 48 by gehzumte...@gmail.com, Jun 6 2014

Not sure this is important, but fwiw this doesn't seem (unless it's already made it to dev channel) to affect my Win8 machine, but it does affect my Win7 machine.

Win7 has an ATI card. Win8 has a nVidia card.

Comment 49 by martinzu...@gmail.com, Jun 6 2014

Today's Canary (37.0.2033.2) 64-bit is again FIXED.

Comment 50 by scottmg@chromium.org, Jun 6 2014

Status: Fixed
Seems OK on 37.0.2033.2 (Official Build 275351) canary x64.

Comment 51 by stan...@gmail.com, Jun 6 2014

Want me to file a follow up bug for #32?

Comment 52 by jsc...@chromium.org, Jun 6 2014

re: #51: Yeah, that seems unrelated so file a new bug.

Comment 54 by wfh@chromium.org, Jun 6 2014

 Issue 381557  has been merged into this issue.

Comment 55 by bugdroid1@chromium.org, Jun 9 2014

Project Member
Labels: merge-merged-1985
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d3cd8f8f748ee77c0abdf8f11ced4796dc303989

commit d3cd8f8f748ee77c0abdf8f11ced4796dc303989
Author: jbauman@chromium.org <jbauman@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Mon Jun 09 21:12:26 2014

Merge 275261 "Revert 265329 "Add SM_CXSIZEFRAME and SM_CXPADDEDB..."

> Revert 265329 "Add SM_CXSIZEFRAME and SM_CXPADDEDBORDER metrics ..."
> 
> This sometimes causes a few issues with multimonitor setups. Also, r274853 fixes it more thoroughly.
> 
> > Add SM_CXSIZEFRAME and SM_CXPADDEDBORDER metrics to get window border size.
> > 
> > Vista added the SM_CXPADDEDBORDER system metric which needs to be included
> > in the border size. The previous code happened to work with 32-bit Chrome
> > because Windows added the padding into SM_CXSIZEFRAME (and set the padding to 0)
> > for backwards compatibility, but with 64-bit that changed.
> > GetSystemMetrics(SM_CXPADDEDBORDER) should always return 0 on XP.
> > 
> > BUG= 361720 
> > 
> > Review URL: https://codereview.chromium.org/243173005
> 
> BUG= 361720 , 379321 
> TBR=jbauman@chromium.org
> 
> Review URL: https://codereview.chromium.org/321463003

TBR=jbauman@chromium.org

Review URL: https://codereview.chromium.org/322803003

git-svn-id: svn://svn.chromium.org/chrome/branches/1985/src@275855 0039d316-1c4b-4281-b951-d872f2087c98

Comment 56 by bugdroid1@chromium.org, Jun 9 2014

Project Member
------------------------------------------------------------------
r275855 | jbauman@chromium.org | 2014-06-09T21:12:26.688991Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1985/src/ui/views/win/hwnd_message_handler.cc?r1=275855&r2=275854&pathrev=275855
   M http://src.chromium.org/viewvc/chrome/branches/1985/src/chrome/browser/ui/views/frame/browser_desktop_window_tree_host_win.cc?r1=275855&r2=275854&pathrev=275855

Merge 275261 "Revert 265329 "Add SM_CXSIZEFRAME and SM_CXPADDEDB..."

> Revert 265329 "Add SM_CXSIZEFRAME and SM_CXPADDEDBORDER metrics ..."
> 
> This sometimes causes a few issues with multimonitor setups. Also, r274853 fixes it more thoroughly.
> 
> > Add SM_CXSIZEFRAME and SM_CXPADDEDBORDER metrics to get window border size.
> > 
> > Vista added the SM_CXPADDEDBORDER system metric which needs to be included
> > in the border size. The previous code happened to work with 32-bit Chrome
> > because Windows added the padding into SM_CXSIZEFRAME (and set the padding to 0)
> > for backwards compatibility, but with 64-bit that changed.
> > GetSystemMetrics(SM_CXPADDEDBORDER) should always return 0 on XP.
> > 
> > BUG= 361720 
> > 
> > Review URL: https://codereview.chromium.org/243173005
> 
> BUG= 361720 , 379321 
> TBR=jbauman@chromium.org
> 
> Review URL: https://codereview.chromium.org/321463003

TBR=jbauman@chromium.org

Review URL: https://codereview.chromium.org/322803003
-----------------------------------------------------------------

Comment 57 by tkonch...@chromium.org, Jun 11 2014

Cc: tkonch...@chromium.org
Labels: Needs-Feedback
Tested the same on win8 chrome version 36.0.1985.67 (Official Build 276210) and observed that the issue is still reproducible as shown in the attachment.

As per comment #56 this seems to be a revert and could anyone please confirm on this fix as this is still reproducible.
361720.png
53.3 KB View Download

Comment 58 by jsc...@chromium.org, Jun 11 2014

tkonchada@ You're using an unsupported version off of the m36 branch, which doesn't have the fix. So, what you're observing is what's expected.

Sign in to add a comment