Sorry for all of the components, I tried to look for discarded-tabs specific component but nothing was found, so I searched for previous issues and gathered the components from there, as well as relevant ones for the input issue.

Next time this happens - can you capture a trace using these instructions: https://www.chromium.org/developers/how-tos/submitting-a-performance-bug

Also - tabs get discarded when you have lots of tabs and they're in the background, right? How do you know the tab was discarded? Or is this just a guess?

Thanks.

This works for me correctly if I load a page and in another tab goto chrome://discards and discard the other tab, switch back and input is working.

Are there more specific reproduction steps?

Windows 10, Chrome 65.0.3325.181

#4 - I tried that as well and it did not work. It only happens when it does so by itself and even then, it is sporadic (but it did happen twice in half an hour, for example).

#3 - I will try to follow those instructions the next time it happens.
This is an educated guess. I Alt + Tabbed to an inactive Chrome window and the tab simply reloaded. This almost only happens when a tab is discarded.
I get a lot of discarded tabs, since, as a developer, the memory pressure is, most of the time, pretty high.

#3 - I disabled "net" and "NetLog" due to personally identifying information leakage, but kept the rest.
It happened with this URL -
https://insights.stackoverflow.com/survey/2018/?utm_source=Iterable&utm_medium=email&utm_campaign=dev-survey-2018-promotion#developer-profile

Also, the "Page Unresponsive" dialog box shows up regarding that non-interactable tab, but the Developer Tools can indeed interact with it, just like I showed in the video. It is not hung, just input-hung. Resizing works (the responsive layout adjusts itself).

Deleted: trace_cannot-interact-with-restored-discarded-tab.json.gz 803 KB

trace_cannot-interact-with-restored-discarded-tab.json.gz 803 KB Download

I am keeping it open (unless it gets discarded again ;)), so let me know if I can get you more data somehow.

Also, the trace shows a warning (I guess it related to me using the mouse wheel on that tab) -
"Import Warning: ProtoExpectation: Please file a bug with this trace. a(10256 10256 MouseWheel MouseWheel undefined undefined undefined undefined undefined undefined undefined MouseWheel MouseWheel MouseWheel MouseWheel MouseWheel)"

*relates

Interesting, the browser process appears to be forwarding events but they're not going anywhere...all renderer processes are still active in the sense they're occasionally processing some tasks from the queue. Perhaps related to issue 823485?

phistuck@, any chance you're running with non-default flags? In particular, site isolation?

To clarify, in issue 823485 I'm seeing browser IPCs being directed back to the browser process. I don't see that here, rather - there's no IPC message at all.

Chrome 66.0.3343.3 dev has the following command line and variations -
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --user-data-dir="C:\Personal\Profiles\PhistucK" --flag-switches-begin --enable-devtools-experiments --enable-experimental-extension-apis --flag-switches-end
c134752e-b8b72c88
61fba06-ca7d8d80
3095aa95-3f4a17df
d52c4ff7-d52c4ff7
47e5d3db-3d47f4f4
4dc30737-b8a5ea08
f9884634-659882c0
121ae2bc-ca7d8d80
9e201a2b-6e3ce1c
57f575bb-3d47f4f4
4b61504a-d25ea691
9773d3bd-f23d1dea
8e3b2dc5-93702590
9e5c75f1-1039a221
c322f799-2dbe5f9
3de1fbf2-ca7d8d80
f79cb77b-3d47f4f4
4ea303a6-ecbb250e
d92562a9-ca7d8d80
447469ba-13d9f35f
7aa46da5-c946b150
2b33233e-d8253d6f
72606c4f-ca7d8d80
58a025e3-c2b41702
b2f0086-d6b26420
2d871858-3f4a17df
4bc337ce-69465896
9a2f4e5b-d226bfeb
1354da85-bdeb9840
494d8760-52325d43
f47ae82a-86f22ee5
3ac60855-486e2a9c
f296190c-dda7873d
4442aae2-a5822863
ed1d377-e1cc0f14
75f0f0a0-d7f6b13c
e2b18481-5c63917a
e7e71889-4ad60575
f5fff3a2-ca7d8d80
2aae5467-b05adee3
94e68624-803f8fc4


I will add similar information from Chrome 65 tomorrow, if it helps, but I think the flags are the same (perhaps without the irrelevant --user-data-dir).

I restored (Alt + Tabbed into) a discarded tab while running a trace, in case it helps. I am not sure it includes everything because the buffer was full when I went back to chrome:tracing, but, still. Attached. Any personally identifying information was hopefully snipped.


Chrome 65.0.3325.162 -
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --enable-devtools-experiments --enable-experimental-extension-apis --enable-features=ParallelDownloading --flag-switches-end

bd23585d-3f4a17df
59aeb88e-3f4a17df
d52c4ff7-d52c4ff7
47e5d3db-3d47f4f4
4dc30737-b8a5ea08
8e3b2dc5-93702590
c322f799-2dbe5f9
2d32f549-734d00b
7aa46da5-c946b150
58a025e3-c2b41702
b2f0086-d6b26420
9a2f4e5b-d226bfeb
494d8760-52325d43
3ac60855-486e2a9c
f296190c-a2200d3b
4442aae2-a90023b1
ed1d377-e1cc0f14
75f0f0a0-d7f6b13c
e2b18481-7158671e
e7e71889-4ad60575
da4aaa01-4d2fac87

Deleted: trace_restoring-discarded-tab.json.gz 3.6 MB

trace_restoring-discarded-tab.json.gz 3.6 MB Download

The discarded and restored tab in the trace has a process ID of 32264.

It looks like the main thread is ticking frames but there's no IO and the mouse messages aren't being processed. Unfortunately, it's hard to tell where we're getting lost to the ether.

I'll add some trace events to InputRouterImpl::FilterAndSendWebInputEvent to determine if we're filtered, dispatched, dispatched non-blocking, etc.

We should also add something on the other end, which looks like WidgetInputHandlerManager::DispatchEvent and DispatchNonBlockingEvent.

dtapuska@, does that sound like the right place to add these? 

FWIW, we've added some extra tracing to track down these kinds of issues, if you see it again, a new trace would be helpful.

The NextAction date has arrived: 2018-04-27

I tried recording a trace using Chrome 68.0.3404.0 (Official Build) canary (64-bit) (cohort: Clang-64) on Windows, but when I stopped recording, it showed an error about eventData.

While recording, I tried to interact with the unresponsive tab and the buffer did not change from 0%. That was a bit weird, but I continued. I went to a not-yet-restored tab, hoping the buffer would go up, but it did not (and that tab was responsive anyway). I stopped the recording in order to start a new one and that is when I got the error about eventData.

Clicking on "Record" does not do anything anymore. Clicking on it again shows a (false) "already recording" error. Looking at the Developer Tools, chrome://tracing/json/categories never finishes loading, which is probably why the recording dialog never shows up.

I guess I have to restart Chrome. :(

Post-restart... No categories show up. The chrome://tracing/json/categories request finishes, but it is [].
I guess chrome:tracing is buggy in Chrome 68.0.3410.0 (Official Build) canary (64-bit) (cohort: Clang-64).

No categories showed up in the previous try (pre-restart), but the chrome:tracing window was not maximized, so I assumed there was no room to show them.

While typing this comment, Chrome suddenly exited without any message (no "Aw, snap!" or anything about crashing).

Maybe some day things will work out.

:(

Deleted: no-categories-chrome-tracing.png 14.2 KB

	no-categories-chrome-tracing.png 14.2 KB View Download

:/ that looks bad, I've never seen that. Perhaps it's just an issue in current Canary? Lets wait a few days...

The NextAction date has arrived: 2018-05-11

ping phistuck@, is this still occurring? Are you able to grab a trace in a recent version?

The canary crashes every tab I open at the moment. Let us wait for a few more days. :(

How about now? :)

#26 - it is my lucky unlucky day (unlucky because the bug still bites).
The trace is attached.

Steps -
I killed open tabs other than chrome:tracing, waiting for extension processes to naturally end and I also killed some unnecessary processes (issue 707509 :(() I found before starting to record. I started recording. I went to the discarded tab and just clicked and rolled the mouse wheel within the tab many times - unresponsive.

Two things, though.
1. When I ticked "System tracing", I got this error when I stopped recording -
While importing:
Error: Cannot determine pointer size of the system trace.
    at EtwImporter.importEvents (chrome://tracing/tracing.js:4509:37)
    at importer (chrome://tracing/tracing.js:1290:232)
    at task.subTask (chrome://tracing/tracing.js:1286:268)
    at Task.run (chrome://tracing/tracing.js:2196:95)
    at runAnother (chrome://tracing/tracing.js:2199:371)
    at runTask (chrome://tracing/tracing.js:2175:57)
    at processIdleWork (chrome://tracing/tracing.js:2180:116)
    at window.requestIdleCallback.timeout (chrome://tracing/tracing.js:2173:81)

2. When I unticked "System tracing" and stopped recording, chrome:tracing showed an information bar at the top -
Import Warning: ProtoExpectation: Please file a bug with this trace. a(12834 12834 MouseWheel MouseWheel undefined undefined undefined undefined undefined MouseWheel MouseWheel MouseWheel MouseWheel MouseWheel MouseWheel MouseWheel)

Would you like two new bugs for those? :(

Deleted: unresponsive-restored-tab.gz 2.5 MB

unresponsive-restored-tab.gz 2.5 MB Download

Thanks! Hm, not sure about the tracing errors. I suppose it can't hurt to file a bug - hopefully it'll find its way to someone more knowledgeable about that. But it looks like the trace recorded some useful info.

The browser process is sending events as expected but they don't seem to arrive at any renderer. The outgoing latency flows don't have a "To" slice. This seems like a routing/mojo issue. The other issue here is we've got OOPIF renderers. The latency infos have a frameTreeNodeId on them but I don't know if we can see each renderer's ID from the trace.

I'd guess that after the tab is brought back to life we don't correctly reconnect the input handler. dtapuska@, any ideas on next steps to debug?

#28 - I would disregard out-of-process-iframes - it happened even when they were not enabled (I forgot the canary enables them, otherwise I would have disabled them explicitly).

Dave, any idea how to proceed here?

Updating priority as this doesn't seem to be a widespread debilitating issue.

#31 - I am rather surprised. I guess most people do not keep many tabs open, so it does not bit them much. And also, it might be a Windows only issue. It can be triggered so easily...
Is there anything else I can do to help you debug this (barring a debugger)?

I tried to reproduce using Linux (using janitor.technology) with Chromium from yesterday, from a few weeks ago and from a month ago, but they kept crashing on SIGBUS adrerr whenever I opened too many tabs, or refreshed Google Maps. Is Chromium relatively stable in the last few weeks? Is it just my configuration (I think Jumbo, component build, out/Default, Linux, --no-sandbox, container...)?

Are you running your own built Chrome? If you're building with DCHECKs enabled then it'll definitely be less stable. Not sure about other configurations. I run Dev channel Linux at work and Canary Mac at home and both have been quite good as long as I can remember.

My own build of Chromium, yes. Sorry for the noob question, but how can I tell whether DCHECKs are enabled?
This is the build command -
gn gen out/Default --args="enable_nacl=false is_component_build=true use_jumbo_build=true symbol_level=1"
ninja -C out/Default chrome

https://github.com/JanitorTechnology/dockerfiles/blob/master/chromium/chromium.dockerfile

https://github.com/JanitorTechnology/dockerfiles/blob/master/chromium/chromium-update.dockerfile



DCHECKs are probably enabled... How can I keep everything the same (debug build, component build, Jumbo...), but disable DCHECKs?

Is the following enough?
gn gen out/Default --args="enable_nacl=false is_component_build=true use_jumbo_build=true symbol_level=1 dcheck_always_on = false"
ninja -C out/Default chrome

I think the default for a non-debug build is off so I think you're fine. dcheck_always_on=false will force it off too. (You'd be seeing very frequent crashes if it's on).

Yeah, well, it crashes a lot. :(
69.0.3446.0 (Developer Build) (64-bit)
1561cea49d7ced9abcaa8c6cbe31c685a223efdf-refs/heads/master@{#562784}
An exemplary crash log is attached.

> lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.4 LTS
Release:        16.04
Codename:       xenial


(Also, I thought DCHECKs were meant not to be hit...)

Deleted: linux-chromium-crash.txt 10.3 KB

linux-chromium-crash.txt 10.3 KB View Download

> Also, I thought DCHECKs were meant not to be hit...

They are...unfortunately we don't quite live up to the rhetoric...