trumbull@ - Thanks for raising. I'm currently unable to reproduce any of those use cases on my Eve which is on Stable 66.0.3359.158.

Are there any other detail/trends we are seeing around such reports?

Looks tricky to repro, I've had a try and can't hit it.  One of the reports is from an eve so we should have a device in the office that can repro.

+dchan/dhaddock to try to repro 

My eve device is Chrome/66.0.3359.137 tried repo steps, issue 842953.

No repro for me attaching image to e-mail (gmail), or the PDF download button, or attaching image to crbug.com.

Tried in eve tablet mode as well.  "Save file as" dialog does _not_ "go completely blank after a few seconds" as reported. (If I click "Save" in the dialog, the browser crashes, which seems to be another issue).

> Screenshot:
> - https://screenshot.googleplex.com/0YwrHJBwtNK.png

That picture is on Google Drive, no?  Anyho, tried uploading a file to Google Drive.  The "Select one or more files" dialog is not blank for me, upload flow worked fine.

Can't repro on link (Chromebook Pixel) 66.0.3359.158 either saving a PDF or attaching a file to gmail.

josafat/dchan/dhaddock/abodeti, any luck trying to repro?

We tried on three devices but not reprod(Chrome OS:M66-10452.96.0/ 66.0.3359.181)

Tried on Kevin, Swanky, coral and Fizz devices.

Here's another report:
https://listnr.corp.google.com/product/208/report/85418492377

There's nothing immediately obvious from any of the system logs.
The versions are:
66.0.3359.158 x 2
66.0.3359.137 x 3
ARC is a mix of enabled and disabled
Boards are gnawty-signed-mp-v3keys, elm-signed-mpkeys, eve-signed-mpkeys x 2, cyan-signed-mp-v3keys
None of these have enterprise enrolled.

Of those boards, we've only got eves to repro on, but couldn't.

+fukino/yamaguchi, any ideas what could cause this behaviour? Have there been similar issues in the past with the file select dialog?

based on the screen capture, looks like the user is trying to upload from local disk to drive via web interface.
I can't repo on my eve with the same build as https://listnr.corp.google.com/product/208/report/85431820005

What is the name of the UMA taken when Files.app starts?

One possible cause is that FSP extension (incl. ZIP Archiver) blocks initialization of volume manager.
I haven't succeeded to repro this issue, but fixing issue 504366 might affect the root cause and fix the issue.

fukino - if that was the case, how does the File Manager show up at all? Everything seems to initialize correctly (if you look closely in this video - https://youtu.be/s829n722Qus - the files display correctly, if only for a split second).

If the volume manager could not initialize, the file manager would not display at all, correct?

Ah, yes, it seems a different issue.
The current directory contents is shown for a second, it means that initialization of volume manager finished. Sasha is right.

Maybe something is causing renderer crash?
When the content is shown in the video, I see a message on the bottom-left corner of Files app.
There might be some file being synced.

I'm sorry, forget about this line.
It seems a normal file-type selector on save-as dialog.

> When the content is shown in the video, I see a message on the bottom-left corner of Files app.
> There might be some file being synced.

I've made a doc with our notes (sorry, Googlers only).
https://docs.google.com/document/d/1zH6grjS_R29d0ckzOwivm7XHRpNO5CEsdUvndeEKr0Q/edit#

Thanks for investigating fukino. Please move future discussions there.

rockot, do the "unsupported native service" or PPAPI OnChannelError logs look familiar?

fsamuel, did viz ship anything in M66 that might do this? One flash of painting, then white?

I don't have access to that doc. :-(

sashab asked if this might be an ash issue. I don't think so. Those dialogs are webui, so I suspect either the renderer is crashing or a graphics/compositor issue.

Things you can do to debug:
* For each listnr report, download the system logs dump. From there you can get the CLIENT_ID. Remove the hyphens. Go to go/crash and search by client id to find crashes from that user. I didn't find much with this. It's possible the users have crash uploading turned off, or maybe this isn't a crash.
* The rest of the logs have a UI section, which is chrome data. I see these things, which seem odd:

[1007:1256:0501/060255.636178:ERROR:service_manager_context.cc(258)] Attempting to run unsupported native service: /opt/google/chrome/chrome_renderer.service
...
[1007:1007:0501/060305.167445:ERROR:storage_monitor_chromeos.cc(210)] NOTREACHED() hit.
...
[1007:1007:0501/060719.704006:ERROR:media_internals.cc(103)] Cannot get RenderProcessHost
...
[1007:1256:0501/061321.924121:VERBOSE2:ppapi_plugin_process_host.cc(444)] ppapi plugin process launched.
...
[1007:1256:0501/061616.584236:VERBOSE1:ppapi_plugin_process_host.cc(480)] PpapiPluginProcessHost<IPv6: 1>OnChannelError()

* If you can repro, Task manager could be used to check whether the renderer is there for the file manager app. There should be two renderers: "Background Page: Files" and "App: Files". A sophisticated user could report back on this
* Use chrome://inspect to inspect the file manager webui

For graphics/compositor stuff the viz team in WAT might have advice, gklassen's team.

Unsupported native service errors referring to content_renderer are almost
always a red herring AFAICT. I think I'm going to explicitly keep that log
silent in that case. There is a chance it could mean that a renderer
crashed unexpectedly, but you see it sometimes even with normal renderer
termination.

Tried with out of space on local disk and Drive
also tried with USB data but not reproduced.  

I think this is not a renderer crash.
* The Client IDs don't have any crashes that would correlate with this time
* Crashing an embedded web contents should display a broken tab icon (see screenshot - you can repro this on linux with the gaia login by launching with --login-manager, clicking "add user", then killing the renderer process with kill -9)
* Crashing the file picker renderer process closes the picker silently (you can repro this on linux by pressing Ctrl+S on any webpage, opening the task manager to get the file manager process id, then killing it with kill -9)
* Crashing the page behind the file picker leaves the file picker open, with the page giving a friendly error (see screenshot)

The client IDs that do report crashes all have at least one instance of "android.util.Log$TerribleFailure: Data directory doesn't exist for package org.chromium.arc.apkcacheprovider" - unlikely to be related, since it crashes at a time uncorrelated with the report.

We may have a googler who is able to repro the issue - CCing him on this bug.

Deleted: kill-page-renderer.png 29.0 KB

	kill-page-renderer.png 29.0 KB View Download

Deleted: kill-gaia-embedded-web-contents.png 4.3 KB

	kill-gaia-embedded-web-contents.png 4.3 KB View Download

When I repro what do you want me to capture that wasn't in the feedback
report or video?

I can bring the device to work if someone in MTV wants to play with it.
Just let me know who and where

Paul - Sasha sent an e-mail yesterday with questions/asks, did you get it?

Getting the device to Weifang in Building 42 otherwise might be the best bet. Unfortunately all of the files app eng team are in APAC.

Got a repro! Thanks so much to pbankhead@ for your help.

To repro:
1) Install the Mobicip extension from the store - https://chrome.google.com/webstore/detail/mobicip/jpafaidkicnfcohbcfegbokibbghpnee
2) Sign up for a free Mobicip account
3) Click the extension icon in the toolbar and click "Install Certificate"
4) Follow the instructions

When you're asked to select a certificate, the file picker displays then goes white.

Adding the VPN team.

The exact error is:
Failed to load resource: net::ERR_TUNNEL_CONNECTION_FAILED www.google-analytics.com/collect:1

It's in the POST message to https://www.google-analytics.com/collect. Form data:
t: event
_v: ca1.6.0
v: 1
an: Files app
av: 66
tid: UA-38248358-9
ul: en-US
sd: 24-bit
sr: 1800x1200
vp: 972x607
cd1: Manage
cd2: Manage
ea: Window Created
ec: Management
cid: b373aec8-3806-440c-9be9-1ebc6ec09c77

The issue seems to occur because we are trying to message Google Analytics with the VPN extension, but the VPN is not fully set up yet because the certificate has not been installed. So the request is blocked 

This might be a surface sync bug...I'm not sure yet. I'll pick it up and see if I can get a repro tonight.

#28 confirmed, tried those repro steps & bingo: Files.App disappears.

Disabling the extension fixes it as well, so we can narrow it down to having the extension enabled.

I'm assuming this is just Chrome OS since Chrome OS has its own save dialog. Is this only happening on M66? Has anyone tried M67 or M68 yet?

Wait, are we saying this is the bug:

"The issue seems to occur because we are trying to message Google Analytics with the VPN extension, but the VPN is not fully set up yet because the certificate has not been installed. So the request is blocked"

In that case, it's not a compositing bug? I'm going to try to repro locally nonetheless.

I'm unable to repro tip of tree. I'll try M67 since this bug has an M67 label.

Reprod on M66 with above extension but not reprod on M67(ChromeOS:10575.40.0/67.0.3396.49) and M68(10684.0.0/68.0.3432.0)

I'm having trouble building M67 locally: "Unknown clang plugin argument: no-realpath" Thoughts?

Updating label from M-67 to M-66. There are no major M66 => M67 surface sync changes AFAIK, so I'm beginning to suspect this is not a compositing bug.

> Failed to load resource: net::ERR_TUNNEL_CONNECTION_FAILED

I believe this indicates a failure to connect to a proxy (not a VPN).

Can you repro if you change the proxy setting to use a non-routable IP, like http://10.0.0.1:8080 ?

Also try `sudo iptables -I INPUT -j DROP` to simulate what happens if the network is not responding.  If that breaks OS dialogs that are supposed to work offline, perhaps Google Analytics is interfering with them.

I am unable to repro this on M66 locally. Unassigning myself because I don't think this is a compositing bug.

Thanks fsamuel@ for your help.

After reproing this bug, you can go to chrome://inspect > Apps > Files > Inspect to open the devtools for that window. You can type window.location.refresh() to reload the picker contents (repro-ing the bug again). You can then click on the error message to find the line of code causing the issue (in this case XMLHTTPRequest.send()), and add a breakpoint there (the {} icon in the bottom left will format the file so its easier to read). Then window.location.reload() again to trigger it.

Before the call to XMLHTTPRequest.send(), the document has:
document.visibilityState = "visible"

After it's called, it changes to:
document.visibilityState = "hidden"

So there is something in the XMLHTTPRequest.send() code that is triggering the DOM to hide.

Can't reproduce on linux build M66, only on device.

Looping in the scheduling and loading teams who might know more about XMLHTTPRequest.

The code for XMLHTTPRequest::Send is here:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/xmlhttprequest/xml_http_request.cc?l=769&gs=kythe%253A%252F%252Fchromium%253Flang%253Dc%25252B%25252B%253Fpath%253Dsrc%252Fthird_party%252Fblink%252Frenderer%252Fcore%252Fxmlhttprequest%252Fxml_http_request.cc%2523JhRvEc%25252FvCxsHB1zRum7d%25252BkbgLR1Z8KSFchcBjvYc%25252BAE%25253D&gsn=send&ct=xref_usages

There's nothing obvious to suggest it's calling WasHidden() on the RenderWidgetHost.

Is it possible the scheduler is trying to do something ckever here, to avoid showing content until it's finished loading or something? I get the feeling something is hiding the DOM contents, but fails due to the proxy/VPN, and the code to re-show the contents is not being called.

> Can you repro if you change the proxy setting to use a non-routable IP, like http://10.0.0.1:8080 ?

Doesn't happen with this proxy, also doesn't happen when the device is offline. 

When the device is offline, though, I get an error in the console:

Uncaught (in promise) {status: "device-offline", la: undefined}

It looks like its trying to call some native code (it's been obfuscated), but it doesn't cause the weird hiding behaviour even though it throws an error.

+yhirano@ for XHR issue (still reading through the thread)

Reg: #44 I don't really recall we're doing anything like that, but adding scheduler people here too.

 Issue 826571  has been merged into this issue.

I cannot reproduce this issue on 67 with the same repro steps. Since it goes to stable in 10 days, it's unlikely we'd be able to push a fix out anyway.

However... this morning I found  issue 826571  which seems to report the same issue happening on 67. In case it is the same root cause, I'll continue to investigate for 66.

If anyone has any ideas what this could be, please let me know.

Is that XHR synchronous?

No, XHR.open() is called with async=true.

Then #43 is surprising to me.

Is the behaviour described in #43 expected for synchronous calls? What is expected to happen if the call fails?

I cannot repro this on a 66.0.3359.158 developer build. It seems to only happen in my release build. Which makes it difficult to debug and even more confusing why it's happening in the first place.

I think we've found the root cause of the issue here (see https://productforums.google.com/forum/#!msg/chromebook-central/wWaz_qMyHGo/ZspHNtuYBQAJ and https://productforums.google.com/forum/#!topic/chromebook-central/PbSAIv5N4g4;context-place=forum/chromebook-central), which seems to be from using a VPN.

I think we should continue to investigate this, but since there's a workaround (uninstalling VPN extensions) I'm lowering the priority.

cernekee@ - I'm certain this is a VPN issue. Can I help you get a repro up and running so you can investigate? Do you know of any major VPN issues that were introduced from 65->66 and possibly fixed 66->67?

We'll also take a precautionary step and remove Google Analytics from the FileManager extension, which was causing the issue in the first place. I don't believe we are using the data from those analytics anyway.

One more thing: the issue seems to occur with the Deferred object passed to Google Analytics:
https://cs.chromium.org/chromium/src/ui/file_manager/file_manager/common/js/metrics.js?rcl=d5fb7d39720b497318399a7267d7a3b02e38eae6&l=96

When deferred.callback is called, with either true or false, it triggers the XHR which causes the window to white out.

Since removing analytics from the Files App is complex, we can disable it by removing the call to the deferred object, which would stop it from firing and prevent the XHR from ever happening.

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

commit 25af83ddf8c991a6adeee3d05dfb0c06a1cd6d64
Author: Sasha Morrissey <sashab@chromium.org>
Date: Fri May 18 06:56:00 2018

Disable Google Analytics in the File Manager

This is a small fix that disables Google Analytics in the File Manager
by removing the call to resolve the callback. Calling the Deferred
object in any way causes an XHR request that causes the file picker to
turn white, so not calling it leaves the Filter unresolved which means
the Analytics server is never contacted (and hence the bug doesn't
happen).

Bug:  842880 , 844280 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: Ie525a88689985d2df1028fc1ba87f954fe158caf
Reviewed-on: https://chromium-review.googlesource.com/1065530
Commit-Queue: Sasha Morrissey <sashab@chromium.org>
Reviewed-by: Joel Hockey <joelhockey@chromium.org>
Cr-Commit-Position: refs/heads/master@{#559818}
[modify] https://crrev.com/25af83ddf8c991a6adeee3d05dfb0c06a1cd6d64/chrome/browser/chromeos/file_manager/file_manager_jstest.cc
[modify] https://crrev.com/25af83ddf8c991a6adeee3d05dfb0c06a1cd6d64/ui/file_manager/file_manager/common/js/metrics.js

> #54

Not expected, but sync XHR's behavior is sometimes strange and it's not surprising to see surprising things.

It looks like the problem is, when a VPN is active for some reason, XHR requests that cause SSL errors try to navigate the extension dialog to an interstitial.

RenderFrameHostImpl::NavigateToInterstitialURL() is called, and the stack trace from WasHidden() is:

#0 0x7f521326227c base::debug::StackTrace::StackTrace()
#1 0x7f52110a52ae content::RenderWidgetHostImpl::WasHidden()
#2 0x7f52110b5a52 content::RenderWidgetHostViewAura::WasOccluded()
#3 0x7f5210e6e74a content::InterstitialPageImpl::DidNavigate()
#4 0x7f5210e6f58f content::InterstitialPageNavigatorImpl::DidNavigate()
#5 0x7f5210e9ee0e content::RenderFrameHostImpl::DidCommitNavigationInternal()
#6 0x7f5210e9ea70 content::RenderFrameHostImpl::DidCommitProvisionalLoad()
#7 0x7f521093e547 content::mojom::FrameHostStubDispatch::Accept()
#8 0x7f521369c646 mojo::InterfaceEndpointClient::HandleValidatedMessage()
#9 0x7f521369bf86 mojo::FilterChain::Accept()
#10 0x7f521369d995 mojo::InterfaceEndpointClient::HandleIncomingMessage()
#11 0x7f5212d5e7fb IPC::(anonymous namespace)::ChannelAssociatedGroupController::AcceptOnProxyThread()
#12 0x7f5212d5c41e _ZN4base8internal7InvokerINS0_9BindStateIMN3IPC12_GLOBAL__N_132ChannelAssociatedGroupControllerEFvN4mojo7MessageEEJ13scoped_refptrIS5_ENS0_13PassedWrapperIS7_EEEEEFvvEE3RunEPNS0_13BindStateBaseE
#13 0x7f5213262b64 base::debug::TaskAnnotator::RunTask()
#14 0x7f5213293ca9 base::internal::IncomingTaskQueue::RunTask()
#15 0x7f52132978bb base::MessageLoop::RunTask()
#16 0x7f5213297c5a base::MessageLoop::DeferOrRunPendingTask()
#17 0x7f5213297ebc base::MessageLoop::DoWork()
#18 0x7f521329a2a9 base::MessagePumpLibevent::Run()
#19 0x7f52132971e9 base::MessageLoop::Run()
#20 0x7f52132ce019 base::RunLoop::Run()
#21 0x5585445c3a6a ChromeBrowserMainParts::MainMessageLoopRun()
#22 0x7f5210d323c7 content::BrowserMainLoop::RunMainMessageLoopParts()
#23 0x7f5210d35666 content::BrowserMainRunnerImpl::Run()
#24 0x7f5210d2e44a content::BrowserMain()
#25 0x7f521179191e content::ContentMainRunnerImpl::Run()
#26 0x7f52137a0014 service_manager::Main()
#27 0x7f521178ff44 content::ContentMain()
#28 0x558543a122c3 ChromeMain
#29 0x7f5205ab52b1 __libc_start_main
#30 0x558543a1213a _start

Adding the Extensions team since its related to extension dialogs, and the interstitials team who might have some ideas.

It seems the interstitials code was refactored in 67 which explains why the old repro case no longer works.

This bug requires manual review: We are only 10 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

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

Merge approved, M67.

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

commit ebe9aac2c553a0e21ad584fcc8217d0524967884
Author: Sasha Morrissey <sashab@chromium.org>
Date: Sat May 19 02:09:09 2018

Disable Google Analytics in the File Manager

This is a small fix that disables Google Analytics in the File Manager
by removing the call to resolve the callback. Calling the Deferred
object in any way causes an XHR request that causes the file picker to
turn white, so not calling it leaves the Filter unresolved which means
the Analytics server is never contacted (and hence the bug doesn't
happen).

Tbr: joelhockey@chromium.org
Bug:  842880 , 844280 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: Ie525a88689985d2df1028fc1ba87f954fe158caf
Reviewed-on: https://chromium-review.googlesource.com/1065530
Commit-Queue: Sasha Morrissey <sashab@chromium.org>
Reviewed-by: Joel Hockey <joelhockey@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#559818}(cherry picked from commit 25af83ddf8c991a6adeee3d05dfb0c06a1cd6d64)
Reviewed-on: https://chromium-review.googlesource.com/1065692
Reviewed-by: Sasha Morrissey <sashab@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#652}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/ebe9aac2c553a0e21ad584fcc8217d0524967884/chrome/browser/chromeos/file_manager/file_manager_jstest.cc
[modify] https://crrev.com/ebe9aac2c553a0e21ad584fcc8217d0524967884/ui/file_manager/file_manager/common/js/metrics.js

Thanks. Merged to M67.

Since 67 goes to stable in 9-ish days, probably not much point merging to M66 (will there even be another stable release in that time?).

Also, FYI, you can repro this bug in Linux using a Chrome-branded build of M-66 (this may be because metrics collection is disabled in Chromium builds).

Meacer - could this be related to  issue 839724 ? The issue seems to be caused from a bad XHR request trying to show an interstitial inside a system dialog.

Reducing priority since a fix for this has been merged to M67, we just need to find the root cause to prevent it happening again in the future.

#66: I'm unable to repro using the steps in comment #28 after reverting the patch for  issue 839724  and the one in comment #64.

That said, this could be related to  bug 839724 . A hypothetical scenario could be as follows:
1. The file selector loads drive.google.com (because ChromeOS file selector can show Google Drive contents)
2. An extension (e.g. a VPN extension) injects into drive.google.com and triggers an XHR that hits a URL with HTTP auth 
3.  Issue 839724  would cause this HTTP auth URL to show a full screen blank interstitial. The modal dialog that accompanies the interstitial is suppressed because this is happening inside the file selector.
4. As a result, the user sees a blank page inside the file app.

What I don't quite understand is how (2) works. It would require an extension to intercept requests made by the file selector dialog which shouldn't really be possible. But perhaps a VPN extension can actually do that.

Thanks meacer@! :)

To repro, you'll need to checkout M66 and build a branded Chrome build.

I think you're correct, with one exception: the file manager loads google-anlytics.com, not drive.google.com :) But that's a promising explanation.

If you're right, https://chromium-review.googlesource.com/c/chromium/src/+/1050935 should fix the problem. I'll build M66 this afternoon and see if this patch fixes the issue.

Can confirm https://chromium-review.googlesource.com/c/chromium/src/+/1050935 fixes the issue! And it's already been merged back to M67, which explains why we can't get a repro on 67.  Issue 826571  was filed before the merge.

I was able to repro the issue in 66, then applied the changes to content/browser/loader/resource_dispatcher_host_impl.cc and was no longer able to repro. I couldn't apply the changes in content/browser/network_service_client.cc since resource_type doesn't exist in the mojom yet. Both these changes are in 67.

Thanks all, I believe the root cause has been found. Marking this bug as fixed.

Great investigation, sashab@!

BTW, #43 is very interesting. Anyone has ideas on why this could happen?

Thanks Satoru! :)

The issue was that the XHR request was causing an HTTP auth URL to show a full screen blank interstitial, with a modal dialog. However, the modal dialog was supressed, just showing the blank screen.

The real issue is that the File Manager dialog was allowed to navigate (since its an app), but shouldn't have (since it's in a dialog). The patch referenced in #70 fixes the way we determine whether a page is in the main frame or not, which correctly sets it back to false for SelectFileDialogExtension.

Thank you for the explanation!

 Issue 848810  has been merged into this issue.

 Issue 872767  has been merged into this issue.