Browser tab non-responsive after resuming

[Quitch]

Prerequisites

• I'm using latest version: v1.3.0
• I've checked Known issues
• I've checked Open issues

Description

Upon resuming from a break, the currently selected browser tab will not respond to clicks or the mouse wheel for several seconds. Other tabs remain selectable and their pages are responsive.

Operating system: Windows 10 x64 Pro 20H2

Browser: Microsoft Edge Version 87.0.664.47 (Official build) (64-bit)

Steps to Reproduce

1. Open Microsoft Edge
2. Open multiple sites across multiple tabs
3. Trigger a break

Expected behavior: Upon break completion the currently selected tab's web page will respond to clicks

Actual behavior: The currently selected tab's web page does not respond to clicks

Reproduces how often: 25%

Additional Information

This is a recent occurrence starting from around v86 of Microsoft Edge. I did not see this behaviour previously.

[BenediktAllendorf]

I had this for a while in Chrome (Windows 10 x64 Pro 20H2) now and couldn't really make sense out of it. But as I'm not the only one (and because I was scared that I had introduced that bug by using the screen-safer mode ^^), I debugged it.

It seems that this is a Chromium bug and in some weird cases, the tab gets inactive and therefore, does not render correctly anymore. The tab is marked as such in Chrome's task manager.

Reproducing this was a bit tricky. I managed to do this by starting a new break right after a chrome tab had loaded a page (meaning, the dev tools showed a loading time aka "Load: 1.23 s") but still was doing something (requesting/rendering stuff) and moving the cursor over the chrome tab while in break. If you manage to make the tab non-responsive even the dev tools freeze and the performance monitor stops. That doesn't seem right, but not sure how/where to report this exactly.

A possible workaround seems to be to first hide the break windows, then close it: master...BenediktAllendorf:hide_and_close. After that, I wasn't able to reproduce the problem. Not exactly sure why this works though. Fun fact, it is even enough to hide only one window (out of multiple when using more than one display) and it does not matter, which one is hidden.

[hovancik]

Yeah, electron is weird. If the workaround doesn't mess with focus (as in: it is then returned to the previous window) I am happy to merge it.

Did anyone else tried the fix? I'll have to test on Mac and Linux for behaviour

[BenediktAllendorf]

Yes, it doesn't change the focus (it stays where it was before the pause the whole time) - at least for Windows 10. I don't expect it to be different in other setups though.

[hovancik]

Do you wanna make a PR? I should be able to test in next few days on Linux and Mac.

[Quitch]

This is still an issue under v1.4.0.

[BenediktAllendorf]

I haven't had it for some time and in a quick test, I couldn't reproduce it.

Are you using Chrome or Edge; which version?

It might be related to hardware/performance, maybe chrome is more restrict with suspending tabs on low memory or something like that.

[Quitch]

Version 87.0.664.66 (Official build) (64-bit)

32GB RAM

Nvidia GeForce GTX 980Ti

[BenediktAllendorf]

Shouldn't be performance then. The specs look fine and it's mostly the same version as I use. I assume Windows?

How often does this happen? Can you reproduce it or does it only happen from time to time?

[Quitch]

Shouldn't be performance then. The specs look fine and it's mostly the same version as I use. I assume Windows?

How often does this happen? Can you reproduce it or does it only happen from time to time?

I'm the original reporter, so all information remains as per the original post. In terms of reproduction, it seems to be anytime the break occurs while the browser window was the window in focus.

[BenediktAllendorf]

I tried again and can't reproduce it.

In the end, I still assume this is a Chrome/Edge bug, which makes it hard to debug. Maybe it depends on power management or some kind of display settings that cause/increase this.

Hopefully, it'll be fixed, but in the meantime, I'm not sure what to test. Perhaps if you could narrow it further down, e.g., it only happens when having multiple monitors or only when you have more than 25 tabs open or something like that.

[Quitch]

I'll see what I can find. In terms of browser usage I'm pretty low-end, 6 pinned tabs (email, calendar, etc.) and no more than 3-4 open tabs at any one time. Only use a single monitor and I'm on the default power profile for Windows.

It seems to be a visual issue, as things like Pg Up and Pg Dn commands are being processed by the tab, they're simply not visible until you switch away and back.

[hovancik]

Stretchly is regular app. The only think I do a bit differently is that I position it "always on top". Could we test if it's the same for some another "always on top" app? We could then pretty much be sure it's bug with Chrome/Chromium that those browsers use.

[KarlBishop]

Coming over from #800 -> I've found using v1.4.0 I now get this issue only intermittently: sometimes the browser freezes on resume and sometimes it works fine.

I've been using v1.4.0 for just over a week and, so far, have yet to notice any difference in my usage/environment between times when the browser has frozen and times when it hasn't.

I'll try to do some deliberate experimenting tonight...

[KarlBishop]

After experimenting I found I can reproduce the error consistently by doing the following:

• Right-click the Stretchly taskbar icon and choose Skip to next break (either Mini or Long break will do)
• Whilst in the break, click all over the screen with the mouse (I've managed to reproduce once with just 4 clicks but it's much more consistent when I do about 10)
• Exit the break by clicking Postpone/Skip this break or by just waiting for the timer to run out
• The browser is now frozen

So I guess it has something to do with accidentally clicking once or twice after a fullscreen break has started (even though it takes lots more clicks to reproduce consistently).

I tested in Chrome, Edge and Firefox and it only seems to affect the Chromium-based browsers, not Firefox.

I also found that although left-clicking, scrolling and typing don't work when the browser is frozen, right-clicking to open the context menu unfreezes it immediately. (It also unfreezes eventually if I left-click-drag over and over for a short period... for science!)

[hovancik]

If it's just Chromium based, looks like some weird Chromium bug. Tried to do your steps on Linux and could not reproduce, so looks like Windows specific. Not really sure what I could try to change here.

[BenediktAllendorf]

It's not all Windows either, I'm not experiencing this anymore. Maybe some driver or Window update did the job.

I guess it's related to Chrome's "Tab throttling and Occlusion Tracking" in v87 (https://blog.chromium.org/2020/11/tab-throttling-and-more-performance.html).

@Quitch and @KarlBishop you could try disabling this flag in Chrome (should be available in Edge as well): chrome://flags/#calculate-native-win-occlusion.

See https://www.reddit.com/r/chrome/comments/j7unuc/chrome_freezes_site_when_not_in_focusalt_tabbing/ and https://www.reddit.com/r/incremental_games/comments/dvm40e/new_chrome_update/.

At least it would be interesting to see whether this helps. But this could result in more CPU load because it's limiting Chrome's ability to suspend (background) tabs.

[Quitch]

I set this flag and don't recall seeing the issue since, so it does appear to be due to this. Not sure why other fullscreen apps, such as games, don't cause this issue. I presume it must be something to do with how stretchly exits, or how it takes focus in the first place. That, or I haven't launched enough fullscreen apps and they do cause the same issue.

[ztrhgf]

For me setting the chrome://flags/#calculate-native-win-occlusion helped!

[uahnbu]

The bug has returned on the latest chrome/edge update. Chrome/Edge has removed the #calculate-native-win-occlusion flag and I can't see other way to fix it.

[hovancik]

Based on this, you can set it via registry key HKCU\Software\Policies\Microsoft\Edge\NativeWindowOcclusionEnabled := 0x0 or going into edge://flags then setting "temporarily unexpire M88 flags" to "Disabled" but I guess you're have to try and see, maybe also some other comments

[hovancik]

Also, maybe they just changed the name? https://docs.microsoft.com/en-us/deployedge/microsoft-edge-policies#nativewindowocclusionenabled

This policy is deprecated, use the 'WindowOcclusionEnabled' policy instead. It won't work in Microsoft Edge version 92.

[uahnbu]

I couldn't find the M88 flags too. I'll try the registry way tho. My temporary fix is to use window mode. The app is still mostly fullscreen and no title bar is shown, which to me is acceptable.

[czlucius]

Firefox also added this feature (Occlusion Tracking) not long ago, and this bug is occurring there as well.
(You could turn off occlusion tracking by toggling widget.windows.window_occlusion_tracking.enabled in about:config)