The web page does show different behavior on chrome compared to firefox. However I didn't see the button animated, it remains hidden while the animation is running and appear after it finishes.

Hi alex4jank@, can you point out the code that animates the .heading-primary--sub elements?

Hi sunxd@

You can find all custom styles (SCSS) in this gist.

https://gist.github.com/jankal/ebda1b527dc869895b81af58572224e7

It's important to say we also used the Bootstrap Framework v4 in this project.

sunxd@ your're right. The button remains out of sight and becomes visible when the animation finished. The problem remains: The button is hidden on first sight.

While trying to debug, I noticed that making drawer-toggle's parent position: relative solves the problem. Also, as you have already said above, when the problem occurs, the drawer-toggle is out of sight  until the animations end; and it is constantly 84px right of its actual position until the end of animations.

Our leading interface developer told me today about some tests he conducted:

Apparently this issue only affects the span.heading-primary--sub. When applying the same @keyframes animation to the span.heading-primary--main, this behaviour doesn't occur.
I haven't verified this yet.

(Bad typo in previous comment completely changes the meaning! Correcting.)

What is happening here is that the translateX widens the scroll container. We then widen .top-header to fit this width (see attached image), which causes the menu icon to go off the screen. As the translateX reduces to 0 the scroll container shrinks to the original size, returning the menu to the screen. The reason for the sudden pop-in is issue 713913; it's not really relevant here. 

I'm not sure what the correct layout behavior is here, given that Firefox doesn't widen .top-header. Let me construct a smaller test-case and run it through the various browsers.

Deleted: Screenshot from 2018-03-20 13-55-42.png 667 KB

	Screenshot from 2018-03-20 13-55-42.png 667 KB View Download

Ah, a very interesting discovery. I am able to reproduce this behavior when using devtools in responsive mode, but not when compositing things and just having a small window. I am also able to reproduce on Android.

Importantly, I have a minimal repro that requires only style and layout so this is a layout bug, not animations. The fixed-position header is being sized to the width of the scroll container rather than to the width of the viewport.

See attached test-case. On Android or under device emulation in devtools the body width and fixed position element width differ.

Deleted: test.html 1.0 KB

test.html 1.0 KB View Download

Considering that there is a test case available now, we worked around the bug on that URL I posted in comment #1. So it's not shown on there anymore.