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 22 users

Issue metadata

Status: Fixed
Closed: Sep 2015
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug

Sign in to add a comment

Ratio of innerWidth to outerWidth is way off for Chrome app windows on a hidpi machine

Project Member Reported by, Nov 24 2014

Issue description

Chrome Version       : 41.0.2229.1

What steps will reproduce the problem?
1. Start a Chrome app.
2. Open devtools for the Chrome app window.
3. Type innerWidth/outerWidth in the console.

What is the expected result?

I expect it to be ~1 Note that this works for regular Chrome windows.

What happens instead of that?

The ratio seems off by the devicePixelRatio. I don't think this is true for OSX on canary.

Please provide any additional information below. Attach a screenshot if

Why am I doing this?
It seems to be the only way to detect the zoom ratio set by the user which I need in a number of places to make my app function correctly.

When the ratio is off, it causes weird artifacts to happen.


Comment 1 by, Nov 24 2014

This is resulting in lots of end user complaints due to the artifacts that occur. 

For example:!topic/hangouts/Gf9yDJwIIGU

Is this a new thing?

Comment 3 by, Nov 25 2014

I tried it on stable and on canary and I could only repro on canary (though some user reports say m38/39... hard to know how reliable that is). I also got a report from a user I trust that it only happened on canary for them.

It was strange that the ratio was correct for normal chrome web pages but only broken for chrome app windows.

I know that innerWidth/outerWidth isn't necessarily supported -- there is no supported way to figure this out unfortunately. Of course an alternate fix I guess is to make the app always have a zoom ratio of 1 (which I think you were working on). Then the apps will need to expose their own control for zoom.

Status: Assigned
Putting in my list so it doesn't disappear
Bisected to:

And confirmed reverting that CL fixes this bug.
Thanks Jack!
BTW this occurs in both browser and app windows. Basically innerWidth is correct, but outerWidth is too small (e.g. on my screen, innerWidth was 1280 and outerWidth was 854).

Comment 8 by, Dec 2 2014

Labels: -Pri-2 -M-41 Pri-1 M-40
Oh.. somehow I thought it was just app windows.

This is going to cause bad compatibility issues if it happens in browser windows too, so it should be fixed in m40.
Status: Started
Working on a fix now

Project Member

Comment 10 by, Dec 6 2014

The following revision refers to this bug:

commit ffd2bddecb7349d0595dd87e802e08e37f18dc28
Author: dmazzoni <>
Date: Sat Dec 06 06:17:04 2014

Make sure Legacy HWND is created and has proper bounds on bounds change.

BUG= 436218 

Review URL:

Cr-Commit-Position: refs/heads/master@{#307160}


Labels: Merge-Requested
Please verify this is fixed on Canary so we can merge.

Labels: merge-questions-applied

Please note that all merge requests must have been on or rolled into trunk
for at least 24 hours to be considered for merging (to ensure full bot
coverage and give an opportunity for any necessary reverts to occur).

To help facilitate this request, if you could please answer the following:
1) Has this change been on trunk for at least 24 hours?

2) Has this change shipped to at least one canary release (where applicable)?

3) Has anyone verified that these changes resolve the issue and cause no new
   crashes (via chromecrash/) or regressions?

4) Why is this necessary for this milestone?


(this message is auto-generated each time the merge-request label is
applied; if you have previously answered these questions kindly disregard)

Labels: -Merge-Requested Merge-Approved Hotlist-Merge-Approved
Approved for M40 (branch: 2214)
fwiw, I tried the Chrome app (which relies on this ratio to be correct or else things look bad) and it looked great.

(PS I tried it on a hidpi Windows machine which is where this problem manifested before.)
Project Member

Comment 16 by, Dec 15 2014

Labels: -Merge-Approved merge-merged-2214
The following revision refers to this bug:

commit 0150c67685ebcf29ba1219fdf12fa741017d1078
Author: Dominic Mazzoni <>
Date: Fri Dec 12 00:05:44 2014

Merge to M40: Make sure Legacy HWND is created and has proper bounds on bounds change.

BUG= 436218 

Review URL:

Cr-Commit-Position: refs/heads/master@{#307160}
(cherry picked from commit ffd2bddecb7349d0595dd87e802e08e37f18dc28)

Review URL:

Cr-Commit-Position: refs/branch-heads/2214@{#274}
Cr-Branched-From: 03655fd3f6d72165dc3c9bd2c89807305316fe6c-refs/heads/master@{#303346}


Comment 17 Deleted

Comment 18 by, Apr 17 2015

2014 Razer Blade (hi DPI) running the current Stable version of Chrome and Hangouts. None of the proposed workaround solved this issue.
This issue is still affecting me. Chrome stable 42.0.2311.135 m (64-bit) on Windows 8.1.
Labels: Hotlist-Recharge
This issue likely requires triage.  The current issue owner maybe inactive (i.e. hasn't fixed an issue in the last 30 days).  Thanks for helping out!

Status: Fixed
It looks like this has been fixed already: a code change landed, and the reporter of the bug said it fixed the problem.

If others are still having problems, please create a new bug.

Comment 22 by Deleted ...@, Nov 13 2015

I see the same issue still here. Ubuntu 14.04, Chrome Version 46.0.2490.86 (64-bit). 

Sign in to add a comment