Rechecked this issue on chrome version 57.0.2987.133 on MAC 10.12.3, not observing any blank pages. As mentioned in the bug, tried refreshing the attached html page many times, still did not observe any blank page. Attached are screen sots for the same.

@ remohammadi: Request you to please try a system restart, relaunch chrome and check again and please provide an update on the same.

Thanks.!

The problem didn't disappear by a system restart. Here is a screen recording of the problem:
https://youtu.be/wHm-3gg-lYU

Thank you for providing more feedback. Adding requester "ranjitkan@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I should note that I had opened the url on this windows before starting the recording. On the first try, it was rendered correctly. I opened another tab and closed the previous one, hopping to create the same behaviour, but it was blank event in the first try in this new tab.

And, I had disallowed all of my extensions in the incognito mode.

Reproduced on 56.0.2924.87 (Official Build) (64-bit) and 59.0.3063.0 (Official Build) canary (64-bit), both Mac OS X. It was necessary to tell Chrome to 'never translate this page' as the translation bar appeared to be causing the paint to work.

After making sure the translation bar never appeared, I refreshed https://honarnama.net/privacy and the page immediately failed to render.

Devtools shows the contents as being there (e.g. it will highlight boxes for the elements) and I see no console errors. The page will appear if you resize Chrome.

However there are also no layers so this does not appear to relate to ThreadedRendering in any way.

I can't reproduce using the instructions in #c7 with Mac OS M-58 or M-59, or linux M-58.

smcgruer@, I'm oassing the bug back to you because you can reproduce it. What happens if you enable tracing and try to get a trace of the page? When we see no content, but DevTools think is it's there, I always wonder which part of the code is not producing content. A trace, with painting information, should be able to tell us if the display item lists are being created, and the compositor layers, etc.

Sure, I can do my best to help. Ran:

$ /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --enable-skia-benchmarking

Then:

1. Opened a new tab, loaded chrome://tracing
2. Started a 'Frame Viewer' trace recording
3. Opened a new tab, loaded https://honarnama.net/privacy (observed the page did paint)
4. Counted to 3 seconds
5. Refreshed the tab with https://honarnama.net/privacy in it (observed the page did NOT paint, white screen)
6. Counted to 3 seconds
7. Stopped the trace.

Result attached; hopefully it is of some use. Let me know if you'd like me to follow any different steps for the tracing.

Deleted: trace_crbug_707542_frame_viewer_trace.json.gz 2.3 MB

trace_crbug_707542_frame_viewer_trace.json.gz 2.3 MB Download

Also confirmed:

1. I can reproduce by loading 'chrome-bug-blank-on-rtl.html' as a file:// URL and refreshing. 

2. If I remove the rtl style from that file, the issue no longer reproduces.

3. I can remove the include of 'http://maxcdn.bootstrapcdn.com/bootstrap/3.3.5/css/bootstrap.min.css' and the problem WILL continue to reproduce.

4. If I also remove the 'http://code.jquery.com/jquery-1.11.3.min.js' include, the problem STOPS reproducing.

So, somehow the inclusion of jquery (or maybe just any javascript?) is causing this?

According to the trace, we are painting something, the raster threads are rasterizing something, but I can't tell if that is going on the screen because I'm not opening the trace with M57 so can't see the pictures.

Removing RTL makes me wonder if this is a layout problem, where we are considering the right edge to be the initial tile (so at 4000 or something) and painting that way. But DevTools shows rects for the content in the right place, which argues against that.

Maybe someone with more experience reading traces looking for frame commit etc could comment?

It's odd that I can't reproduce.

Comparing UpdateLayers_BuiltPropertyTrees for the 2 calls (after step 3 and after step 5, @333496318177 and @333499034860) some layer_ids have changes, sequence number is increased from 1 to 2, and the strange thing is `10001.0` as the 4th element of post_local of the last node in transform_tree, which was 0 in the first call.

Unable to reproduce this issue on Mac OS 10.12.4 using chrome latest stable #57.0.2987.133 by following steps mentioned in the comment #9. Observed the page loads as expected after step-4. Attaching screen-cast for reference, please have a look and let me know if anything is missing from my end.

Thanks!

Deleted: 707542.mp4 2.4 MB

	707542.mp4 2.4 MB View Download

This is interesting! We have a bug that appears to reproduce only on Mac OS X (I am unable to reproduce on Linux), and only confirmed to reproduce for one user and one Chromium dev so far (me). (I wonder if it could be a driver bug?)

Adding Ali and Wei because of the notes about the transform tree in comment #15.


Additionally, a fun change now that I've updated to stable:

1. 57.0.2987.133 - Reproducing the issue with chrome-bug-blank-on-rtl.html has become more difficult (still happens, just that it works properly for quite a while sometimes). Reproducing the issue on https://honarnama.net/privacy is still trivial for me.

2. 59.0.3064.0 - Reproducing the issue with both approaches is still trivial.

Whoever ends up working on this, myself and my Macbook are at your disposal for reproducing :)

Deleted: chrome-bug-blank-on-rtl.html 197 bytes

chrome-bug-blank-on-rtl.html 197 bytes View Download

The sequence number increase in property trees is expected. The 10001 value in post-local transform suggests there's a layer whose position has an x coordinate of 10001 (which would put it way offscreen, unless some ancestor layer has a counteracting transform).

smcgruer@, can you reproduce using a Chromium build from trunk?

It would be good to know whether we can debug it when we manage to figure out how to reproduce it.

Not likely to matter, but maybe, what are your Mac System Scrollbar settings? Could everyone who has reproduced report back?

I bring this up because we have a few painting bugs that depend on scrollbar settings. But given this happens without any scrolling, it seems unlikely to matter.

We have now reproduced this on two low-DPI macbooks, a high-DPI macbook, and a low-DPI mac cylinder thing that Rob has under his desk.

We'll attempt to bisect here in WAT.

Bisected to the following range

You are probably looking for a change made after 432958 (known good), but no later than 432987 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/d9c529de305db6eb0dde1052a39c9dd4b06f9bc9..e0c42d84a1d10ad30c7488b13be67ee17a3707b4

Looks like this regressed with f5a4f9d38de7403d172ad20f78c462048eae37bc https://codereview.chromium.org/2501723003

The value of "Show scroll bars" settings has a significant effect on the bug behaviour on my machine. Originally it was on "Automatically based on mouse or trackpad", and it causes the page to be paint in the first load, but not in reloads. When it is on "When scrolling", even on the first load the page is not painted. And "Always" makes the bug disappear, at least I wasn't able to reproduce it.

Thank you so much. I can confirm that using "When Scrolling" for scroll bar setting causes the bug to reproduce for me. That should also help in finding a fix.

Ah, yeah, this looks like another case where we accidentally get by relying on scrollbar changes to trigger a layout/paint. The issue is likely deeper than my patch but I'll take a look when I get to a Mac.

I also should note that this bug is not new. Unfortunately I reported it too late, and I don't remember when was the first time I observed it. It can be more than a year ago! The probability of observing this bug has changed during these times.

(For example, as I've noted in the bug report description, there is a scroll-on-load script as a workaround in the source of the honarnama.net page, bug since a few weeks ago, I noticed the bug still happens on some of the pages of the website, on pages which are shorter than the height of the window. Maybe it the behaviour of rendering of scrollbars in Mac has changed in the latest Mac OS update)

(I guess scrollbar is not the root cause! It's just making the bug disappear by forcing Chrome to repaint the page – just a guess :")

I can also see the issue on a Linux device (don't try the testcase just once, try it for multiple times) and I can confirm that I was seeing this for a long time on RTL sites, thanks for the report Reza. I see the issue on the same testcases and also Persian Wikipedia https://fa.wikipedia.org

Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Rasterization: Hardware accelerated on all pages
Video Decode: Software only, hardware acceleration unavailable
Video Encode: Hardware accelerated
VPx Video Decode: Software only, hardware acceleration unavailable
WebGL: Hardware accelerated
WebGL2: Hardware accelerated

GPU0	VENDOR = 0x10de, DEVICE= 0x11fc
GPU1	VENDOR = 0x8086, DEVICE= 0x0416 *ACTIVE*
GL_VENDOR	Intel Open Source Technology Center
GL_RENDERER	Mesa DRI Intel(R) Haswell Mobile

This probably is related to chrome://flags/#overlay-scrollbars also or that helps better reproducing of it as because if I reset all of my experimental flags and just enable this I will get more chance on seeing this on the original html testcase.

You can see the issue in the attached file.

When I remove direction: rtl from body tag and add it to wrapper div, the problem will be fixed.

jQuery might be related to this bug as well.

Deleted: blank-page.zip 39.3 KB

blank-page.zip 39.3 KB Download

Looks like the page in the original report would temporarily create an element with a high negative x coordinate. This would modify the scroll origin. Since layers are positioned in physical directions, the compositor's scroll layer gets a really high x position. When the element is removed, the scroll origin changes but the scroll offset does not. Looks like we were relying on the scrollbar change to trigger the repositioning on the compositor and this no longer happens.

I've got a fix in progress that explicitly recomputes the composited layer's position when the origin changes. Should be landing soon.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9c51c9ab54994c6baa9eedde1eb86b549dd8e314

commit 9c51c9ab54994c6baa9eedde1eb86b549dd8e314
Author: bokan <bokan@chromium.org>
Date: Wed Apr 12 02:27:58 2017

Update layer position on scroll origin change

Layers on the compositor are positioned relative to the physical origin
in the top left corner, regardless of writing direction. In Blink, the
scroll offset is relative to the scroll origin which changes based on
writing direction. This means that changing the scroll origin, without
changing the scroll offset, still requires updating the scroll layer's
position on the compositor.

Previously, this happened by accident as a change in scroll origin would
often cause scrollbar existence to change and this would implicitly
position the compositor layers through calling
PaintLayerCompositor::FrameViewDidChangeSize. This call is unneeded when
using overlay scrollbars since no sizes changed so I removed it in
https://crrev.com/f5a4f9d38de7403d172ad20f78c462048eae37bc. This caused
us to miss positioning scroll layers in cases where we wouldn't otherwise.

This patch adds a step after a compositing update that checks if the
scroll origin changed and explicitly updates the scroll layer position.

BUG= 707542 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2812523003
Cr-Commit-Position: refs/heads/master@{#463904}

[modify] https://crrev.com/9c51c9ab54994c6baa9eedde1eb86b549dd8e314/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] https://crrev.com/9c51c9ab54994c6baa9eedde1eb86b549dd8e314/third_party/WebKit/Source/core/frame/FrameView.h
[modify] https://crrev.com/9c51c9ab54994c6baa9eedde1eb86b549dd8e314/third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp
[modify] https://crrev.com/9c51c9ab54994c6baa9eedde1eb86b549dd8e314/third_party/WebKit/Source/web/tests/WebFrameTest.cpp

Confirmed fix in dev channel on Linux.