I can also confirm that my page zoom level is 100% in all browser tests, as shown in the screenshots.

URL from which the 1st and 3rd screenshot examples are observable on my system: https://threejs.org/examples/#css3d_youtube

Appears to match Firefox for me in Chrome 56.0.2924.3 on Linux.  Also tested Chrome 54 on Windows via browserstack.com and it appears the correct size for me (screenshot attached).  Perhaps this is a GPU-specific issue?  Please try disabling the "Use hardware acceleration when available" setting, does it still reproduce?  If not, please include the contents of chrome://gpu/

Issue persists even after disabling the "Use hardware acceleration when available" setting and restarting Chrome.

I am attaching chrome://gpu/, one before disabling the setting, and one after...

Deleted: gpuBefore.html 204 KB

gpuBefore.html 204 KB View Download

Deleted: gpuAfter.html 44.7 KB

gpuAfter.html 44.7 KB View Download

Issue persists with hardware acceleration disabled (attached):

Deleted: Issue-With-Hardware-Acceleration-Disabled.png 53.6 KB

	Issue-With-Hardware-Acceleration-Disabled.png 53.6 KB View Download

Chrome matches Firefox on linux, and Firefox, Edge, and IE on Windows. THis is Chrome 56.

Could you please try installing Chrome Canary and see if the issue reproduces for you there?

Issue is non-existent on a new installation of Chrome Canary, for some reason.

I can confirm that issue persists after an update (via About Google Chrome) of my standard Chrome installation to Version 55.0.2883.87 m :

Deleted: MyChrome55VsNewCanaryChrome.png 75.5 KB

	MyChrome55VsNewCanaryChrome.png 75.5 KB View Download

Deleted: MyChrome55VsNewCanaryChrome2.png 679 KB

	MyChrome55VsNewCanaryChrome2.png 679 KB View Download

I can confirm that after uninstalling Chrome and re-installing latest Chrome (55) from the web, the issue still persists:

Deleted: FreshInstallOfChrome55VsChromeCanary.png 685 KB

	FreshInstallOfChrome55VsChromeCanary.png 685 KB View Download

1. When you uninstalled - did you check the option to also delete your local profile?

2. If you use the --user-data-dir="c:\some\path" command line flag, does the issue still reproduce?
See -
https://www.chromium.org/developers/how-tos/run-chromium-with-flags
For details about running with flags.

I didn't delete my local profile. However, I can confirm that the issue still persists after using the --user-data-dir="c:\some\path" command line flag, as demonstrated:

Deleted: FreshChrome55WithUserDataSomePathFlag.png 747 KB

	FreshChrome55WithUserDataSomePathFlag.png 747 KB View Download

Sorry, I did not notice you mentioned it is working in the canary build (I thought it was a fresh stable Chrome installation).

That is good, this means it was fixed at some point between Chrome 55 and Chrome 57.
Since you are able to reproduce this consistently, you could track down the change (or revision range) that fixed it by using bisect-build.py -
https://www.chromium.org/developers/bisect-builds-py
(It requires Python)
If you find the revision, the team may merge it (if it is relatively safe) to Chrome 56 (I do not think Chrome 55 will get it merged, because it is not critical).

Sorry for asking you to do the work, but since no one can reproduce, no one can bisect or confirm...

Thank you for providing more feedback. Adding requester "rbyers@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Ah, now that I know this is fixed in Chrome 57 I have been able to reproduce it:
Windows Chrome Stable 55.0.2883.87: fail
Windows Chrome Beta 56.0.2924.28: pass

This may be High-DPI specific - what does your CSS/JS pixel ratio say at http://mydevice.io?  On my SurfaceBook it's 2.0.  I suspect low-dpi systems (1.0) may not see an issue (perhaps it's bigger by exactly the pixel ratio).

So yes that probably means it's been intentionally fixed.  It's too late to merge a fix into Chrome 55, but Chrome 56 goes stable in about a month so the fix will be deployed then.  Sorry for the trouble!

Let's try to get a bisect of this just so we can find the right bug to dupe against and confirm that tests have been added to prevent this from regression.

Yes, my pixel ratio is 1.5:

Deleted: MyDeviceDotIO.png 778 KB

	MyDeviceDotIO.png 778 KB View Download

Great, thanks.  Updating the summary to describe the issue.

So for whoever does the bisect, you'll need a high-dpi Windows machine (or perhaps other OS also - I was testing on low-DPI Linux previously).

I searched for a related bug fixed in M56 but haven't found anything.

Able to reproduce on Windows 10 and Ubuntu 14.04 using chrome stable #55.0.2883.87 whereas unable to reproduce in the latest canary #57.0.2969.0.

Reverse Bisect Information:
=====================
Good build:  56.0.2916.0  Revision(431463)
Bad Build :  56.0.2915.0  Revision(431137)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/9fd0d17c0367d1d763fc7b8d8b046a583472588e..6be6a794e7ea4dcc2b9e12da2aa02d00b3c84f1c

From the above change log suspecting below change

Review url:  https://codereview.chromium.org/2482753002

pdr@ - Could you please check whether this is caused with respect to "fta2012@gmail.com" change, if not please help us in assigning it to the right owner.

Please note that the author of this change doesn't have a chromium id, hence assigning it to one of his reviewer.

Thanks...!!

Thank you for the bisect!  So yes this bug was definitely fixed explicitly in  issue 242685  for M-56, and tests were updated to prevent regression.  We can now safely call this a dupe of  issue 242685 .