Able to reproduce the issue in Android. Observed the image is not loading.

Steps Followed:
1. Launched Browser
2. Navigated to https://www.deltashares.com/products/sp-500/overview/ 
3. Observed the image is not loading.

Chrome versions tested:
61.0.3163.98, 64.0.3251.0

OS
Android 8.1.0

Android Devices
8.1.0; Pixel Build/OPM1.171019.004

Below is the bisect info
=======================

Chrome Good Build -- 61.0.3160.0
Chrome Bad Build  -- 61.0.3162.0

https://chromium.googlesource.com/chromium/src/+log/61.0.3160.0..61.0.3162.0?pretty=fuller&n=10000

Results from pre revision bisect --
You are looking for a change made after 488017(GOOD), but before 488018(BAD).
 
From the above revision range suspecting the following --
https://chromium.googlesource.com/chromium/src/+/6933fe8a1b1d14e0d36a69cb27ef026217595d95

@bokan -- Could you please look into the issue, kindly re-assign if this is not related to your changes.

Please navigate to below link for log's and video--
go/chrome-androidlogs/779120

Note: This issue is not observed in Desktop.

Thanks!!

It would be good to have a fix, during M64 timeframe since this is a recent regression.

Thanks for pinging, I missed this. Will investigate it today.

Some investigative notes: this is in fact related to the inert-visual-viewport change pointed out above.

The page is reading window.innerWidth to determine whether to apply mobile/tablet/desktop styles during loading. We now use the layout viewport width, which is what the page actually wants to read in this case. The problem is that the layout viewport size is 980 until the viewport meta tag is read and we do a layout.

I think the underlying bug here is our arcane way of sizing the fixed container: issue 437303. Fixing that to match other browsers should also fix this. However, that might be difficult to do without impacting root-layer-scrolls ( issue 417782 ). I'll look into any mitigations that might be possible if that's the case.

The specific site appears to have been fixed.

Having taken a closer look, I actually think there isn't anything for us to do, this is expected behavior change from the inert-visual-viewport change. When script reads the values of window.innerWidth/innerHeight, it'll depend on whether it happens before or after the viewport <meta> tag is loaded. If the script reads before the <meta> tag is parsed (likely to be uncommon), it'll see 980px wide. Otherwise, it'll see whatever the <meta> tag specifies. I think this is rational though it does have some compat impact. I'll keep an eye out for similar issues but it doesn't seem to be common.