What does this "triage" means: "needs-bisect".
Note that the other triage on M66 is in fact wrong as it affects all existing versions wince at least Milestone 60 (possibly even before). And visibly I'm not alone to have seen this defect in the network pane with all the unlisted requests.

I've tested it also in the separate Canary build, I have the same defect (on Windows 64-bits versions). It seems that the 64-bit version has dummy implementation of a necessary interface. I had no such problem with the 32-bit build (also for windows 10).

It seems that this bug is related to the suppression of code moved to the separate "NetLog Viewer Web App" but this code was not just necessary for viewing external log files, but needed as well for the network pane (without loading any log file), so we have now a dummy interface in Chrome that does nothing.

The list of requests shows up just fine here in Chrome 66. Passing this to DevTools folks to triage this.

Unable to reproduce the issue on the reported version 66.0.3359.117 using Win 10 with the below mentioned steps. Attaching Screen cast for reference. 

1.Opened Chrome Browser with reported version. 
2. Switched to  Developers panel
3. Navigated to Network pane
4. Opened Google home page and forcing the refresh of the current page
5. Observed the waterfall and List of requests remains displayed accordingly. 
Attached is the screen cast for reference.

Request you to check on a new chrome profile with out any flags/extensions and update with Observations.

Thanks!

Deleted: 834709.mp4 3.5 MB

	834709.mp4 3.5 MB View Download

The extensions are those from Google itself, the antivirus (Avast), and a password manager (Dashlane), nothing else.
anyway I don't know how extensions can hook on the listener that captures requests.
Note: the waterwall is present, so there's a apture working, but the requests list is still empty.
And I already reainstalled Chrome, and then tried with a new separate installation of Canary build, and I have the same result.
If I use the 32-bit build of Chrome, I can see the list of requests.

You probably wanted to reproduce it with the 32-bit version of Chrome !

Thank you for providing more feedback. Adding the requester to the cc list.

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

When I refresh this page in Chrome, I only see ONE request listed: the request for the HTML content of the IFRAME that displays the attachment (your video), but not any script loaded from the main page and not this page itself.

No problem with the 32-bit version (with the same connected profile)

Apparently I see that there's some transient requests appearing when I refresh, but it is then cleared from the list (the waterfall itself is not cleared).
Pressing F5 normally first clear the list and then captures the requests, but sibily the event that clears the list is lauched asynchronously out of order after the first requests are done (I have a fast Internet connection with 1Gbps FTTH)

Apparently the bug is caused by Google Hangout:

Disabling it solved the problem. When I have reenabled it, it displayed an alert saying that it required a new authorization in my account, in order to enable it again.

Apparently the extension was enabled but not authorized, and then this caused an issue there where an interface was not working an dreturned without doing anything.

If "Google Hangouts" required a new authorization, it should have been disabled automatically in the browser instead of continuing to run it and causing the issue, or there should have been an authorization request displayed.

In 32-bit Chrome, that extension was disabled automatically, but not in 64-bit Chrome.

So there's a bug in the authorization API for Google extensions, if the authorization is still denied, it causes the list of requests to be flushed. Google Hangouts is apparently attempting to process this list, it fails to get the privilege, and this failure causes the list to be deleted globally in the browser (Google Hangout is apparently using a global access to that list, instead of requesting a copy). It may be an issue in the accessor used by extensions (probably that extension is using a developer/debugging API to do that, but Google Hangouts should not use that API intended to be used only by the local user in the context of the Chrome global UI in the developer panel).
However I don't know why this does not affect the 32-bit version of Chrome (may be that version is implicitly creating a copy of the list it retreives for that API, via a 32-bit to 64-bit thunk, but the 64-bit version jsut gets a direct pointer without copying the list itself: if the authroization is denied, the exception handler will fluch the list, but if the list is not a copy, it gets flushed).
This may be a security issue in 64-bit Chrome: malicious extensions can directly interact with the global list of requests and possibly infect them using a direct access (for example they could use it to perform cross-site scripting or spying user input, or run arbitrary code of their choice within the tabs of their choice).
There's probably a forgotten level of isolation (beware of some malicious Russian extensions, notably those for "Mail.ru" that are extremely intrusive, or extensions that still exist for silent cryptocurrency mining: they could run in global context of the browser and will be difficult to stop).

Don't let any extension to get a direct access to the list of network requests, they can only get a read-only copy if properly authorized, and those extensions needed for debugging and that can modify the list of requests should remain in the context of the local user and should have a specific authorization (probably only enabled if the user activates the "Developer mode" at top the "Extensions" panel).

Note: the screenshot above which gives a list of extensions does not say which one are activated.
I may have several extensions listed in my data submitted (or in my Google account) but most of them are disabled (some of them are even incompatible for my current device installation, or may be activated only on one device).
I do not find the same list as those in your screenshot.
For the current issue it is now solved given that I have disabled Google Hangouts and reactivated (where I had to grant a new permission which was not asked before, but visibly necessary, and that probably caused an unexpected exception when Hangouts listed as active was denied some access in some internal API used with the Chrome console debugger).
There's probably an unchecked assumption in the way permissions are granted. And I think this is a serious security hole which could be exploited by some malwares trying to defeat some services by making some features of the console unusable to track their activity. That console MUST remain usable in all cases, no data flush should ever occur automatically when the console is used, even if some extension requests an authorization and is denied the acsess to the information that we want to see in our console (all waht these extension will then get is just empty or fake data sets).

Tested the issue using reported version 66.0.3359.117 on Win 7 and 10 and could not reproduce the issue as per the steps mentioned below.

Steps
------
1.Opened Chrome Browser with reported version. 
2. Switched to  Developers panel
3. Navigated to Network pane
4. Opened Google home page and forcing the refresh of the current page
5. Observed the waterfall and List of requests remains displayed accordingly.

Removing bisect label as this issue isn't reproducible from TE end. Please add it back if required

Requesting @eostroukhov for further updates on this issue
 
Thanks!

There was an additional step described: I had a "Hangouts" extension registered in my account, it was already activated, but it was changed to require a new authorization that was not requested. I had to disable that extension and reenable it to see the authorization request. Once the authorization was given the extension was enabled to run (without it it could not be enabled: the list of requests is filled and remains fileed, not flushed in the middle because some API in Hangouts had its authorization unexpectely denied and caused that extension to generate an unhandled exception, which caused the list of requests from the main document to be constantly cleared, except requestes coing from iframes which are in a separate document, completely recreated from scratch when we relaoad the main document frame: apparently the fact of refreshing the main frame caues some events to be delayed, and and if they depend on existing extensions thatr are monitoring the main window or other tabs to see when documents are being reloaded, they can cause the list of requests attached to the main document to be flushed multiple times if these extensions have some of their authorizations denied, and this was the case of Google Hangouts when it was updated to a new version without asking for a new required authorization, notably for privacy, and I suspect that this was the result of express changes in Hangouts for the European GDPR, which was not completely tested, it was assumed in the existing code that the requests could never fail because that permission is supposed to be granted if the extension itself is already installed and continues to run after the update of its implementation).
Note also that this was not a problem of cache: this bug occured after an uninstallation of Chrome, or after a new separate installtion of the Canary version. And it affected Chorm Release and Chrome Canary in their x64 version only, not the 32-bit version (I suspect this is related to the way the exception handlers are handled, or to the fact that some 64-bit native code passes through a thunking mechanism which requires copying data in 32-bit Chrome, and not share it via memory mappings in the 64-bit Chrome Release and 64-bit Chrome Canary: even if the authorization exception also occurs in the 32-bit version with the updated Google Hangouts extension, I think it has different consequences and this does not affect the global 64-bit structure used by Chrome: Google Hangouts is probably using an internal unofficial/unsupported API in the Debugger/console part of Chrome, and this could be a sign that applcaition on the net can dangerously interact with this debugger to bypass the isolation mechanism!).
In my opinion, this suggests that there's a security hole in Chrome: it could be even more serious that Spectre/Meltdown which are more difficult to mitigate but require extensive code to compute timing statistics and perform correct prediction of what is happening somewhere else in another process or in the VM itself: here it could be simpler to exploit that bug if this is waht I suspect: a problem of isolation in the 64-bit version of Chrome's developer console, caused by incorrect permission checking for extensions.