Unable to complete the signup process to enter in to this game using both mobage and gree account, Getting error message saying "From the area of ​​use, GREE new member registration has ended". Due to this I an unable to check this issue.

kg@ - Do you have any suggestion how to get in to this game? Is there any other sample tescase or test account from where we can login and check this issue from Chrome-TE end.

Thanks!

My suggestion on how to register would be to use the Mobage path and then sign in with a G+ account. That's what I did, and I think it won't require any additional steps on your part. If that's not possible, I will set up a test account for you.

It occurred to me that there is also a 'Chrome App' version of the game, with id 'eablgejicbklomgaiclcolfilbkckngf':
https://chrome.google.com/webstore/detail/%E3%82%B0%E3%83%A9%E3%83%B3%E3%83%96%E3%83%AB%E3%83%BC%E3%83%95%E3%82%A1%E3%83%B3%E3%82%BF%E3%82%B8%E3%83%BCchromeapps%E7%89%88/eablgejicbklomgaiclcolfilbkckngf?utm_source=chrome-app-launcher-info-dialog

This app also exhibits the same DPI issue, and if memory serves it has a simplified registration/sign-up flow for G+ accounts. You should get the mobage sign-in screen immediately, and clicking G+ will (after you sign in) get you going.

Deleted: Screenshot 2016-08-31 03.12.46.png 130 KB

	Screenshot 2016-08-31 03.12.46.png 130 KB View Download

Able to reproduce on Windows-10 High Dp device using chrome latest Canary M55-55.0.2845.0 .

Bisect Information:
---------------------
Good build: 54.0.2794.0 
Bad Build : 54.0.2797.0 

Change Log URL: 
---------------------https://chromium.googlesource.com/chromium/src/+log/af2f49ba57ed217d06e69830f325c9ba7e7ce0bd..57b70dae30c2bc7d60e70efd8ebae83e01fe9119

From the above change log suspecting below change
Review URL: https://codereview.chromium.org/2134413002

Note: This issue not observed on MacBook Pro on chome latest canary 55.0.2845.0 

wangxianzhu@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

I think a more likely responsible change is this one:
https://chromium.googlesource.com/chromium/src/+/f449a7f4828a5610b1e21b8d2e378555fa59ca7b

Digging around indicates that use-zoom-for-dsf has an impact on layout and bounding rect values (see https://bugs.chromium.org/p/chromium/issues/detail?id=599656#c23) which could explain why it is changing the DPI scaling behavior for this game.

My release channel updated to Version 53.0.2785.89 m just now and it has acquired the broken Hi-DPI behavior I reported. Now everything is small :-( 

Doing some testing in the latest release channel build, it appears that bounding client rects (via getBoundingClientRect) in this game are now incorrect - My chrome extension does some basic DOM inspection to align UI with in-game dom elements and the client rects returned for those elements seem to be incorrectly scaled by some unusual ratio - seemingly around 1.33 but even that's not quite right.

As per comment #6 I to suspect the same
https://chromium.googlesource.com/chromium/src/+/f449a7f4828a5610b1e21b8d2e378555fa59ca7b

Review-Url: https://codereview.chromium.org/2044963004

Removing wangxianzhu@ from owners list and adding bsep@ for more updates on this bug.
 

I've been unable to come up with an isolated repro that clearly demonstrates this issue, but the behavior of getBoundingClientRect has definitely changed, as has the general layout/rendering behavior in high-DPI modes. The changes are subtle but the appearance of element outlines is different, for example, and layout coordinates seem to round differently in 53.x.x and above than they did in 52.x.x. See attached screenshot (52 on the left, canary 55 on the right). I checked and 53.x.x shares 55's rendering and layout behavior here.

What's unclear to me is how the problems are being triggered for this game in particular...

Deleted: Screenshot 2016-09-01 02.12.17.png 105 KB

	Screenshot 2016-09-01 02.12.17.png 105 KB View Download

I take that back. I found the key to reproducing the problem - it's setting 'zoom: reset' on the parent element (in this case, <body>. In the game's case, one of the divs that acts as parent to the rest of the content.)

The attached HTML content renders differently in 52.x.x and 55.x.x. I would argue that the behavior in 53 and up is incorrect, but I have no idea what the spec has to say here, and zoom is an incredibly confusing css property.

In both cases the 'zoom: reset' also hinders the use of ctrl-mousewheel in this content, which makes it impossible for the end user to compensate for this bug :/

Deleted: dpiclientrect.html 2.7 KB

dpiclientrect.html 2.7 KB View Download

52.x.x on the left, 55.x.x on the right, with zoom:reset applied.

Deleted: Screenshot 2016-09-01 02.20.34.png 100 KB

	Screenshot 2016-09-01 02.20.34.png 100 KB View Download

looks like zoom: reset; isn't working correctly with use-zoom-for-dsf.

bsep@, let me know if you don't have time to work on this.

Adding oshima@ because he'd be interested in this.

I can take a look, I doubt this only affects Windows. Thanks for the test page.

Sorry oshima I didn't see your comment earlier.

After some research the new behavior is definitely broken. But it's not really clear what zoom:reset "should" do (it almost certainly shouldn't disable page zoom either) so I need to do some investigation to determine what we'll actually change.

In the meantime, since it's not really clear to me why you want to disable page zoom but not dsf zoom, I recommend simply not using zoom:reset.

Sorry I thought the OP was a developer for the game. As a workaround if you remove zoom:reset from the game's CSS (via developer tools or extension) everything should work like you want it to.

zoom: reset seems to be blink/webkit specific feature, according to this.

https://developer.mozilla.org/en-US/docs/Web/CSS/zoom

I believe this can be used to cancel user zoom. I made a simple test page here:

https://jsfiddle.net/77amjgqk/2

and the "Hello Reset *" should be displayed at the same size as "Hello 1.0".

With use-zoom-for-dsf, the size of Hello Reset is 1/2 of the Hello 1.0 (except for a bug mentioned below).

I noticed a few other bugs though.
1) In above example, the last "Hello Reset 2" is somehow has the same size of Hello 1.0f.

2) When you zoom in (using ctrl + / menu), "Hello Reset Nested" becomes the same size of "Hello 2.0 Nested".
  Reloading (re-running) fixes it. This happens with and without use-zoom-for-dsf.

#18: When I talked to tabaktins@ he thought that it was "supposed" to only cancel out explicit scale() calls and was surprised to learn that it also canceled the user's page zoom. The mozilla page is probably a description of Chrome's empirical behavior. So I think we could remove that "feature" if necessary.

sgtm too as it's not a standard.

This must have been added in WebKit era, so I guess no one really owns this in Blink. +eae@, tkent@ in case they know who.

#16: Thanks, I added some logic to inject a stylesheet with 'zoom: normal !important' when the user is on Chrome 53 and it does address this problem (while also enabling mousewheel zoom). This suffices as a workaround for now, and I'll be able to disable it for versions of Chrome without the bug. Sadly most players of the game don't use my extension, but ideally they are all on 96dpi monitors.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cffab1f32b8add2dbb2cfdc746b488526663b63b

commit cffab1f32b8add2dbb2cfdc746b488526663b63b
Author: bsep <bsep@chromium.org>
Date: Fri Sep 16 21:43:07 2016

Add use counter for CSS zoom:reset and zoom:document.

In order to deprecate or remove these values we need to measure usage.

BUG= 642613 

Review-Url: https://codereview.chromium.org/2345583005
Cr-Commit-Position: refs/heads/master@{#419284}

[modify] https://crrev.com/cffab1f32b8add2dbb2cfdc746b488526663b63b/third_party/WebKit/Source/core/css/parser/CSSPropertyParser.cpp
[modify] https://crrev.com/cffab1f32b8add2dbb2cfdc746b488526663b63b/third_party/WebKit/Source/core/frame/UseCounter.h
[modify] https://crrev.com/cffab1f32b8add2dbb2cfdc746b488526663b63b/tools/metrics/histograms/histograms.xml

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c96485dba1223b9a7c6378b4a5b6c5a883e2b3e1

commit c96485dba1223b9a7c6378b4a5b6c5a883e2b3e1
Author: bsep <bsep@chromium.org>
Date: Thu Feb 16 04:44:06 2017

Deprecate CSS values zoom:reset and zoom:document.

Add a deprecation message and output to the console when zoom:reset or
zoom:document are used in preparation for their removal.

BUG= 664668 , 642613 

Review-Url: https://codereview.chromium.org/2689063002
Cr-Commit-Position: refs/heads/master@{#450871}

[modify] https://crrev.com/c96485dba1223b9a7c6378b4a5b6c5a883e2b3e1/third_party/WebKit/LayoutTests/fast/css-generated-content/table-with-scrollbar-corner.html
[add] https://crrev.com/c96485dba1223b9a7c6378b4a5b6c5a883e2b3e1/third_party/WebKit/LayoutTests/fast/css/deprecated-zoom-properties-expected.txt
[add] https://crrev.com/c96485dba1223b9a7c6378b4a5b6c5a883e2b3e1/third_party/WebKit/LayoutTests/fast/css/deprecated-zoom-properties.html
[modify] https://crrev.com/c96485dba1223b9a7c6378b4a5b6c5a883e2b3e1/third_party/WebKit/LayoutTests/fast/css/zoom-font-size.html
[modify] https://crrev.com/c96485dba1223b9a7c6378b4a5b6c5a883e2b3e1/third_party/WebKit/LayoutTests/fast/css/zoom-on-unattached.html
[modify] https://crrev.com/c96485dba1223b9a7c6378b4a5b6c5a883e2b3e1/third_party/WebKit/Source/core/css/parser/CSSParserContext.cpp
[modify] https://crrev.com/c96485dba1223b9a7c6378b4a5b6c5a883e2b3e1/third_party/WebKit/Source/core/css/parser/CSSParserContext.h
[modify] https://crrev.com/c96485dba1223b9a7c6378b4a5b6c5a883e2b3e1/third_party/WebKit/Source/core/css/properties/CSSPropertyAPIZoom.cpp
[modify] https://crrev.com/c96485dba1223b9a7c6378b4a5b6c5a883e2b3e1/third_party/WebKit/Source/core/frame/Deprecation.cpp

For the record, I am still stuck injecting a stylesheet with a zoom override to get expected DPI scaling in current versions of Chrome. Is this intended, and the deprecation notices serve to make sure developers know to fix their content? Or is there a separate issue at work that will be fixed?

#25: Yes, it's expected for now. The deprecation message is a warning to developers that we are going to remove the zoom property soon. Once we do that you won't have to inject a stylesheet anymore.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/36095a2996117ee0b77d0badc9b237ea4d686521

commit 36095a2996117ee0b77d0badc9b237ea4d686521
Author: bsep <bsep@chromium.org>
Date: Wed Apr 26 21:04:22 2017

Delete deprecated properties zoom:reset and zoom:document.

BUG= 664668 , 642613 

Review-Url: https://codereview.chromium.org/2821843002
Cr-Commit-Position: refs/heads/master@{#467454}

[delete] https://crrev.com/2a3ea87b91e10ff6f9d978f52e7d5efd70572610/third_party/WebKit/LayoutTests/fast/css/deprecated-zoom-properties-expected.txt
[delete] https://crrev.com/2a3ea87b91e10ff6f9d978f52e7d5efd70572610/third_party/WebKit/LayoutTests/fast/css/deprecated-zoom-properties.html
[modify] https://crrev.com/36095a2996117ee0b77d0badc9b237ea4d686521/third_party/WebKit/Source/core/css/properties/CSSPropertyAPIZoom.cpp
[modify] https://crrev.com/36095a2996117ee0b77d0badc9b237ea4d686521/third_party/WebKit/Source/core/css/resolver/StyleBuilderCustom.cpp
[modify] https://crrev.com/36095a2996117ee0b77d0badc9b237ea4d686521/third_party/WebKit/Source/core/frame/Deprecation.cpp
[modify] https://crrev.com/36095a2996117ee0b77d0badc9b237ea4d686521/third_party/WebKit/Source/core/frame/UseCounter.h

Merge was requested and approved for the latest patch in  bug 664668 .

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/30a210d86eaf8ca5bf2941a6bbee44b867300c6b

commit 30a210d86eaf8ca5bf2941a6bbee44b867300c6b
Author: Bret Sepulveda <bsep@chromium.org>
Date: Thu Apr 27 22:42:27 2017

Delete deprecated properties zoom:reset and zoom:document.

BUG= 664668 , 642613 

Review-Url: https://codereview.chromium.org/2821843002
Cr-Commit-Position: refs/heads/master@{#467454}
(cherry picked from commit 36095a2996117ee0b77d0badc9b237ea4d686521)

Review-Url: https://codereview.chromium.org/2846783005 .
Cr-Commit-Position: refs/branch-heads/3071@{#277}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[delete] https://crrev.com/1c0d3e95679659c1b01785b9fc666aa9a8de0431/third_party/WebKit/LayoutTests/fast/css/deprecated-zoom-properties-expected.txt
[delete] https://crrev.com/1c0d3e95679659c1b01785b9fc666aa9a8de0431/third_party/WebKit/LayoutTests/fast/css/deprecated-zoom-properties.html
[modify] https://crrev.com/30a210d86eaf8ca5bf2941a6bbee44b867300c6b/third_party/WebKit/Source/core/css/properties/CSSPropertyAPIZoom.cpp
[modify] https://crrev.com/30a210d86eaf8ca5bf2941a6bbee44b867300c6b/third_party/WebKit/Source/core/css/resolver/StyleBuilderCustom.cpp
[modify] https://crrev.com/30a210d86eaf8ca5bf2941a6bbee44b867300c6b/third_party/WebKit/Source/core/frame/Deprecation.cpp
[modify] https://crrev.com/30a210d86eaf8ca5bf2941a6bbee44b867300c6b/third_party/WebKit/Source/core/frame/UseCounter.h

Fixed via removing support for the offending CSS property in M59.

Verified this issue on Win 10, using chrome latest beta M59 #59.0.3071.36 by following steps mentioned in the original comment. 

Observed the scaling of the content is matched with the monitor. Hence adding the TE- Verified label

Please refer the screen cast

Deleted: 642613.mp4 4.6 MB

	642613.mp4 4.6 MB View Download