Google has rolled back an experimental WebContent Occlusion feature that caused major disruption for enterprise users using Chrome in a multi-user terminal server environment. While the issue is now fixed, enterprise admins are furious that this feature was enabled in the first place without their knowledge or permission.

For approximately 5 months, Google has been experimenting with a feature called WebContent Occlusion that hides the content of not-visible tabs so that they use less resources and cause less battery drain.

A Chrome developer stated that this feature caused no problems in their period of testing and on Tuesday morning Google quietly enabled it for users in Chrome 78 Stable release.

"The experiment/flag has been on in beta for ~5 months. It was turned on for stable (e.g., m77, m78) via an experiment that was pushed to released Chrome Tuesday morning. Prior to that, it had been on for about 1% of M77 and M78 users for a month with no reports of issues, unfortunately. - chrome://flags shows you experiments."

Once the feature was enabled, all hell broke loose for enterprise users in terminal server environments such as Citrix and Windows Terminal Server when they discovered that Chrome became unusable.

Chrome meltdown on terminal servers

When WebContent Occlusion is enabled, Chrome will detect when a tab is not being used and make its content hidden to reduce resources and cause less battery drain.

While this feature was being tested on Chrome Beta users for some time, it was not properly tested in enterprise terminal server environments.

This became evident in Citrix or Terminal Server environments when a user locked their screen, every other user on that server would have their Chrome tabs suddenly become a white screen.

Chrome White Screen Issue (Source: Cody)

This happened because web occlusion was enabled in the browser for the locked screen and hid their browser content. At the same time, it also caused the content in tabs for every other user on the same terminal server to become hidden as well.

The only way to fix this was to unlock the screen, but this issue was constantly repeated as other users on the Terminal Server would once again lock their screen as they left their desk.

As you can imagine this was a nightmare for large organizations with large terminal server environments.

An admin named Cody who works for a company with 800 employees shared the issue with BleepingComputer last night and told us it came out of nowhere and that they had no idea what was going on at first.

"It was seemingly random until we noticed a pattern. If another user on the same server locked their workstation, (Win Key + L) other users on the same server would have all the content in their Chrome tabs turn white. Chrome was completely responsive during this time, just the content area of Chrome was blank. Re-launching Chrome would temporarily resolve the issue, until another user locked their workstation."

This could not have come at a worse time as companies gear up for the holiday season. For example, a Costco employee posted in the Chrome bug report and stated that 1,300 call centers were impacted by this problem.

"We have over 1300 Call Center agents ramping up for the holiday season that were affected."

After hundreds of reports from enterprise users who were affected by this, Chrome developer David Bienvenu stated he rolled back the change and disabled the feature.

For the rollback to take effect, users are required to restart the Chrome browser in order to pull down the new configuration.

Enterprise admins are furious

Enterprise admins are furious that Google has the ability to quietly enable features in their environment without even a heads up and provide no way for admins to block these changes.

System admins try to run a tight ship where any changes are carefully thought out and tested before going live. For a company to be able to reach into their organization and make undetectable changes without their permission or knowledge is extremely frustrating to administrators.

This is even more frustrating for companies who have invested in change control and monitoring software, which as Cody explained, did not detect these changes.

"Even in environments that have change controls and change monitoring software, Google was able to silently make changes to "stable" versions (Chrome 77 and 78 were the versions affected) of Chrome without anyone ever knowing."

In the Chrome bug ticket about this issue, this frustration was clearly evident by many of the admins who stated that Google needs to add a new policy that could be enabled to block these silent feature changes.

Bienvenu did not think it is currently possible, but said it will most likely be discussed.

"I hear you loud and clear bout being able to opt out of these experiments. I don't know if it's currently possible, but if not, I'm sure it will be discussed."

How to disable the WebContent Occlusion feature

As Google has already pushed the change to disable WebContent Occlusion, most users should no longer be affected by this bug. If they are, all users of a terminal server should close Chrome and restarted it.

Once restarted, Chrome should pull down the new changes and have WebContent Occlusion disabled.

If you are still affected, though, you can manually disable this feature by going into chrome://flags and setting the #web-contents-occlusion and #calculate-native-win-occlusion flags to disabled.