disabling `overflow: hidden` also works but that defeats the point of the design.

The focus call is likely doing a scroll into view or something like that.

But I'm deferring this to the animation team to investigate.

Re #2, yes the focus call is scrolling into view. If you observe the scrollLeft of the .boxes element it changes after the call to focus. I think this is the expected behavior at least for overflow: auto|scroll, though it seems dangerous to do this for an overflow: hidden element where the developer may not be expecting it to happen.

Able to reproduce this on the latest stable(52.0.2743.82) and the latest canary(54.0.2803.0) on Windows-7, Mac OS 10.11.5 and Linux Ubuntu 14.04.

This is regressed in M-36.

Last good build: 36.0.1965.0
First bad build: 36.0.1967.0

Changelog: https://chromium.googlesource.com/chromium/src/+log/946cdb61e3aa5f6b7c1c8b4f143ca9099e50ccf9..755bd92cb16a37d39cf9b31e7dd5ed7df916e97a

There is blink changelog in the above range which is opening a blank page:https://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=/trunk&range=172819:172885&mode=html

From the blink changelog b/w 36.0.1965.0 and 36.0.1967.0: https://chromium.googlesource.com/chromium/blink/+log/c0ae1b653a201f4fba421dee3dad7eaf7e1874c2..c1639d903abb315a663dcb2734b67f61f1b0567e?pretty=fuller&n=10000

Suspecting: https://codereview.chromium.org/250773002 (trchen@) or https://codereview.chromium.org/260113004 (chrishtr@)

Could anyone of you please take a look and help in investigating this further.

Thank you! 

transition and transform were unprefixed in M36; prior to that those fields would have been ignored. Not sure why the unprefixing didn't show up in the bisect range, however.

Updated example with prefixed versions included: http://codepen.io/anon/pen/yJGyJo

I attempted a bisect with:
$ python tools/bisect-builds.py -a linux64 -g 116827 -b 267191 --verify-range --use-local-cache -- --no-sandbox
and if I have done this correctly I think this is a non-regression issue.

While transitions are involved, I don't think this is an issue in the animations code. Bumping over to Blink>Focus, but could also be layout? I'll stay cc'd on the bug in case you need input from the animations team.

(as a Blink>Focus owner) I'm not exactly sure what is going wrong in the example,
as I'm not familiar with animation - according to comment#3 by flackr@
scrollIntoView() is working as expected?

This is working as intended in that focus calls scrollIntoView. Overflow: hidden is used quite a bit to implement custom scroll behavior, we cannot break that.