Sorry for the almost faux labeling as a crash, but it still crashes in the canary, even though it is unrelated to the rendering issue at hand.

(The original page had the Bootstrap CSS, the Bootstrap RTL CSS, jQuery and some text on the page. jQuery, on DOMContentLoaded, adds an element with certain styles and removes it, which caused the rendering issue)

Workaround (the easiest) - set user-scalable to yes.

Crash IDs for the canary -
Crash ID b95f6c91-c072-4df6-a299-365095685d5f (Server ID: 8170076700000000)
Crash ID af1e6fd6-03a8-4774-bdac-f8e17ede3b36 (Server ID: da02076700000000)
Crash ID 856d7fff-5d12-4010-bc10-58a9473eaa39 (Server ID: 093ffb6700000000)
Crash ID 91b6940e-2b4c-4ccf-a0d8-a81139ba86d0 (Server ID: f06c076700000000)
Crash ID 7269c08e-c911-4c2a-9d38-7b1952b3b1a5 (Server ID: 6c74076700000000)
Crash ID c6aad152-aaf6-4ac4-9313-f3ec05812381 (Server ID: 50c2076700000000)
Crash ID 3978bfd2-e0a2-4646-8d8e-ace31a86ee7e (Server ID: c4c6690500000000)

I also tried using Chrome 54 with --disable-gpu and the issue reproduced, so it is unrelated to any hardware acceleration.

Able to reproduce it on Mac, 54.0.2840.87 (gray page).
White page on canary 56.0.2915.0, no text.

The text shows up on Chromium 43.0.2332.0 (320518).
Marking this as a regression and increasing the priority as a result.

Assigning to TL as part of daily triage process

I also can repro this on 55.0.2883.75 and 46.0.2486.0 on linux. No crash, but using the following steps, I get an empty page:

1.) Open previously attached Test.html
2.) Use Ctrl+Shift+m to activate device mode
3.) Select "ipad" from the menu at the top
4.) Refresh the page

Requesting a bisect in case this is a regression issue.

I believe it has something to do with RTL, as the page is RTL. Removing it resolves the issue.

Doesn't look like a DevTools issue, since it's reproducible on Chrome for Android (per original report).

What about that bisect?

Must the status be "Untriaged" in order to get a bisect?

Tested in chrome stable #54.0.2883.87 and canary #56.0.2966.0 on Mac 10.12.2, Ubuntu 14.04 & Win 10.0 able to reproduce the issue.
Below are the Bisect Details:

Bisect Info:
=============
Good Build: 46.0.2462.0 (Revision - 339796)
Bad Build: 46.0.2463.0 (Revision - 340009)


Bisect URL:
=========== 
You are probably looking for a change made after 339988 (known good), but no later than 340011 (first known bad).
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/cb788f4fe9b1e42aa39bb84a98a485f676702b6a..566c0f3fd02f97a23cf82528b776bb440032b5e1

From the CL above, assigning the issue to the concern owner

@ jbauman : 
------------------
Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review URL: https://codereview.chromium.org/1254463004

#18 -
Did you bisect Android builds, or did you bisect desktop builds with the Developer Tools?

Not crashing anymore, a white page is shown instead a gray page.

Tested on mac 10.12.2 using chrome canary M57 #57.0.2983.0 and a blank white page is seen .

@jbauman-- Could you please look into this.

Thanks!

#21 - can you reverse-bisect this on non-Android?
The change that #18 found seems to only affect Android and this is happening across platforms using the Developer Tools.

Adding hdodda@ to cc and requesting a new bisect to answer #22

Bisect provided in comment # 18 , is provided using desktop builds and tried the bisect using old script again using deskop builds on windows 7 .

Bisect Info:
=============
Good Build: 46.0.2462.0 (Revision - 339796)
Bad Build: 46.0.2463.0 (Revision - 340009)

You are probably looking for a change made after 339993 (known good), but no later than 340011 (first known bad).

CHANGELOG URL:

 https://chromium.googlesource.com/chromium/src/+log/fd42e198a2d776d2be459fc752a068e8388a1742..566c0f3fd02f97a23cf82528b776bb440032b5e1

From the above list of CL's unable to find the suspect and requesting someone to help in assigning to the concerned owner.

Note : Issue is still seen on latest canary M58 #58.0.3010.0 

Thanks!

While the change does say "WebView", I think the mobile emulation code goes through the code path it touches -
https://chromium.googlesource.com/chromium/src/+/85432c82c466a62d6f56ee3d15def0affececa61

Since it starts with -
 if (!TopControlsHeight()) 
And I believe that the mobile emulation viewport does not have top controls for that matter.



The original report (reported directly to me, using a much bigger test case that included jQuery, Bootstrap and more) mentioned that scrolling the page fixed the issue, which sounds right, according the the mentioned change.

Perhaps this flow change caused it -
+    UpdateViewportContainerSizes();
+
     active_tree_->SetRootLayerScrollOffsetDelegate(
         root_layer_scroll_offset_delegate_);
-
-    UpdateViewportContainerSizes();

@hush - can you take a look, please?

Thank you.

Can anyone else take this as hush@ is inactive according to Monorail?
Thank you.

Since the code in cc/, this is a compositing issue, right?

The issue occurs when the meta tag looks like this:
<meta name="viewport" content="width=device-width, user-scalable=no">

Removing either of width=device-width or user-scalable=no makes the problem go away. So clearly these are interacting negatively with the repaint or whatever is causing the problem.

I'll follow up on phistuck's theory that it's the UpdateViewportContainerSizes change.

This is mobile only. It manifests on desktop only when emulating the mobile platforms, and it's due to mobile-specific meta tags.

Deleted: Test.html 466 bytes

Test.html 466 bytes View Download

I will assume you accidentally put iOS and remove it. :)

Did you ever get around to look into this schenney?

Not yet. Still on my queue. Feel free to take it over.

This has existed since M-46 which does not count as a regression for bug tracking purposes.

Note that this bug manifests with a slightly different test case (no RTL, no viewport statement, but with CSS Grid) without the Developer Tools or device mode, on Windows and Linux (at least). See  issue 702427  for details and a test case.

Not a P2 given the workaround of removing meta-viewport tags. I've started looking at it again, however.

#36 - no, this is not an applicable workaround when you develop a mobile website (exactly the scenario that triggered this bug).

Yes, the meta tags are important. I should not have implied otherwise.

In any event, I am looking into it. The patch that is suspected of causing it has had way too much change around it to reasonably revert for testing. Our method for updating scroll has changed.

#38 - sorry, you meant that removing the user-scalable=no token would resolve this as a workaround (and not only the entire viewport meta-tag) - you are correct, it is an applicable workaround.

(Also, since it requires dir=rtl, the priority probably is lower. Unfortunately for us, right-to-left application authors)

Well that was a waste of time, for me at least. Or the value in not acting quickly. In Canary it now works as intended. Please verify, to make sure I'm not mistaken.

And verified on the Android Canary.

Indeed, verified. Sorry for wasting your time. :(

You didn't waste my time. :-) I should have checked too. You did what a developer advocate should do, which is push us to fix stuff.