By the way, the issue can be reproduced also by emulating mobile in Chrome's Developer Tools, but not 100% systematically 

Just found out: this only happens if the created element exceeds the viewport width.

So, this is clearly not a usability feature, it's just a bug. To recap:
- if you add content that is outside the viewport above the top or below the bottom, but it does not exceed the viewport width, the window doesn't scroll automatically to the newly created content's position
- if the created content exceeds the width, then it does

If the rationale behind this is that content that is added to the document is likely to be intended to be viewed by the user and if it is outside the screen this is likely to be unintended (which is already a too dangerous assumption), it doesn't make any sense to change the behavior depending on whether or not the content exceeds the viewport width.

This seems to already be fixed in Canary, I don't see the scroll jump there. teo8976@, could you confirm?

There is still an issue that we reset the zoom level when a wide element gets added (try making the added element 2000px wide instead) since we try to zoom out to fit the whole page. I'd guess that's also the logic that previously caused the scroll jump but something changed recently. We probably shouldn't do that after the page finishes loading, but there's always edge cases. You can work around this by specifying a minimum-zoom in your viewport <meta> tag or by putting all your content in a container with `overflow-x: hidden` to prevent the content becoming wider than your viewport.

This is related to  issue 438588  and more generally issue 437303

Given that this is "mostly" working and there's workarounds, I don't think this is high priority and I don't currently have the cycles to get to it any time soon. 

> There is still an issue that we reset the zoom level when a wide element 
> gets added (try making the added element 2000px wide instead)

What do you mean by "wide"?
Are you saying that there is an absolute threshold other than the width of the device screen? That there is a difference between adding a 1000px wide element and adding a 2000px wide element even if both are wider than the device screen?

If that is the case, that's certainly a nonsense behavior.

When the page has the meta tag 
  <meta content="width=device-width, initial-scale=1">

you should never, ever zoom out automatically no matter what.


Well actually I have just tested, changing the width in my example and I don't see any zoom out, fortunately.

But I am testing the stable version, not Canary, which I don't even know how to get.


> This seems to already be fixed in Canary, I don't see the scroll jump there. 
> teo8976@, could you confirm?

Does Canary for Android even exist?? I went to https://www.google.es/chrome/browser/canary.html (which is the first result on google for "chrome canary") with my Android phone, and it tells me:
"Chrome Canary is currently not available on the linux platform.
You can try Chrome Canary for Windows 32-bit, Windows 64-bit or OSX."


By the way, unrelated suggestion: at https://www.google.es/chrome/browser/canary.html one of the first things I'd expect to find is an explanation of what Canary is in the first place.

Sorry, right, on Android you can get get Chrome Dev channel which is a little behind what Canary would be but very close to bleeding edge. Unfortunately, it seems to still be broken there so the fixing change must be quite recent.

> Are you saying that there is an absolute threshold other than the width of the device screen?
> That there is a difference between adding a 1000px wide element and adding a 2000px wide element
> even if both are wider than the device screen?

I'm saying that during loading, if you have an element that's wider than the screen size (like setting an explicit with on a div), we'll load the page zoomed out so that the full width of the content can be seen. The difference between 1000px and 2000px is that the wider div will cause us to zoom out further.

>When the page has the meta tag 
>   <meta content="width=device-width, initial-scale=1">
> you should never, ever zoom out automatically no matter what.

Agreed, and I don't think we do normally. Actually, on second inspection, I didn't notice the page had a meta tag at all. It seems that what I was seeing is that the viewport tag was not getting applied at all. I'll take a look after all as there seems to be something fishy going on.

> I'm saying that during loading, if you have an element 
> that's wider than the screen size (like setting an explicit
> with on a div), we'll load the page zoomed out so that the 
> full width of the content can be seen.

Oh, ok, that is without the viewport meta tag, which I see you had missed.

Ok, I took a deeper look and there is indeed a bug which I'll fix shortly. The problem is that inserting a wide element like this grows the layout viewport. The reason we do this is the size of the layout viewport determines how far you can zoom out. We want to be able to encompass all the content horizontally when we zoom out fully so we make the layout viewport the same width as the content. When we grow the layout viewport horizontally like this, we also expand vertically to keep the same aspect ratio.

The issue here is that we're already fully scrolled. When we make the layout viewport's height bigger, it means the maximum scroll position shrinks so that's why the scroll jumps. The correct thing to do here would be to anchor the scroll so that the visual viewport remains in the same location.

You can work around this for now by explicitly setting a minimum-scale in your viewport meta tag. Having an explicit minimum-scale means that we won't make the layout viewport any larger than needed for this scale, even if you have wider content.

I think you changed the title of the issue when you hadn't realized we were talking about the case when there is a viewport metatag. I'd suggest to change it back, as it is quite confusing now. There's no zooming out involved, the issue is an unexpected scroll jump.

 Issue 707888  has been merged into this issue.

Can not reproduce this issue on 58.0.3029.83 Android.

Confirmed, see attached test case for adding wide element when scrolled at bottom. I suspect scroll anchoring may have helped here.

Deleted: insert-wide.html 650 bytes

insert-wide.html 650 bytes View Download