Oh, fun! I am seeing the following behaviors on my Windows 10 machine:

M66 - no observable issue.
M67 - elements appear to 'shake' during the transition (it looks like they are rapidly snapping back and forth between two pixels).
M68 - elements do not 'shake' during transition, but at the start and end some of them (maybe all, hard to see) all appear to shift a single pixel up/left and then down/right.

Once I get into the office I will attempt to reproduce on Linux and run a bisect to see where all these interesting behaviors have come into play...

Another issue:
Set Windows DPI to 150% and Chrome's font size to 40px.
Sometimes pressing the gear changes position of the neighboring gears. I think this should not happen according to the standard.

Unfortunately this issue does not appear to reproduce on Linux, as far as I can tell :(. I will attempt to get access to a Windows machine in the office so that I can perform a bisect of the behavior.

In the meantime, since this appears to be a regression from Stable to Beta, marking Bug-Regression and RB-Beta.

cc flackr@ as an FYI.

Got the Windows lab machine up and running, and able to reproduce. I am beginning a bisect, first to determine where between 66 and 67 the initial bad behavior was introduced.

After that, I will double-check the 'reduced' bad behavior in 68, and bisect as necessary to see where the behavior changed again.

Results from first bisect (local repro file used attached):

You are probably looking for a change made after 543287 (known good), but no later than 543292 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/bc3e6fa5756624cf270d4c7667d6b58a10d3fc3d..fccebeda09156e5e392f97181beb4fc608483dcb

This seems likely to be a SPv175 regression since https://chromium.googlesource.com/chromium/src/+/3a3c78a924a686ed0d3f90d765b00cdd78453e11 is in the stack there.

However, I am not able to reproduce on canary so doing the reverse bisect now (beta to canary).

Deleted: index.html 5.0 KB

index.html 5.0 KB View Download

Finished the reverse bisect.

You are probably looking for a change made after 555806 (known bad), but no later than 555825 (first known good).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/66da0224bbb29d288f3cee13d3a6d2f6cb33af0c..76dfd502f1d1ae2288746e01fac1aa69751741de

Based on that list, I suspect https://chromium.googlesource.com/chromium/src/+/8ab29f09a7bbf904ba1567a26ff28b9cf4d6953a fixed this.

Assigning to wangxianzhu@ to confirm comments #7 and #8. Xianzhu - we probably want to merge 8ab29f09 to 67 to fix this issue.


Regarding the additional issue mentioned in comment #3, I will fork a new crbug to investigate that.

Thanks for the report and bisects.

The CL mentioned in #c8 is in M67 now, and has been released in beta 67.0.3396.30. Can you verify on 67.0.3396.30? If the bug still reproduces, we need to merge another CL between r555806:r555825.

See attached screencast. However I don't think your change made it into beta until 67.0.3396.36; see https://storage.googleapis.com/chromium-find-releases-static/8ab.html#8ab29f09a7bbf904ba1567a26ff28b9cf4d6953a

Deleted: 2018-05-09 14-02-56.mp4 357 KB

	2018-05-09 14-02-56.mp4 357 KB View Download

Re comment #3, I have forked issue 841439 to track the neighbour-shifting behavior.

Tested in 67.0.3396.40.
The jitter is greatly reduced, thanks wangxianzhu. But 2 issues are still there:
1. From #c3
2. From #c2: "elements do not 'shake' during transition, but at the start and end some of them (maybe all, hard to see) all appear to shift a single pixel up/left and then down/right." This issue is well visible in real application on my machine.

Sorry, I mixed up the CL with another one. According to https://www.chromium.org/developers/calendar, the fix will be released in 67.0.3396.40 beta today.

I'm looking into the #c2 issue.

I think #c2 and #c3 are the same issue. Will track it with bug 841439.