Stories
Slash Boxes
Comments

SoylentNews is people

posted by chromas on Saturday November 16 2019, @02:34AM   Printer-friendly
from the papa-google-knows-best dept.

Google Fixes White Screen Problem in Chrome, Admins Furious

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.

[...] 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.

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.

[...] 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 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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Saturday November 16 2019, @04:24AM (6 children)

    by Anonymous Coward on Saturday November 16 2019, @04:24AM (#920883)

    Does Chrome even allow for this?

    Back when it was a new browser I sought to give it a try. It made two bad impressions out of the gate: one was that it didn't ask me for any kind of installation options. The other was that it was a few hundred megabytes.

  • (Score: 2) by NotSanguine on Saturday November 16 2019, @04:43AM

    by NotSanguine (285) <NotSanguineNO@SPAMSoylentNews.Org> on Saturday November 16 2019, @04:43AM (#920887) Homepage Journal

    Does Chrome even allow for this?

    Yes. [superuser.com]

    Back when it was a new browser I sought to give it a try. It made two bad impressions out of the gate: one was that it didn't ask me for any kind of installation options. The other was that it was a few hundred megabytes.

    See the link above WRT Chrome installation behavior (%PROGRAMFILES% vs. %USERPROFILE%)

    As I mentioned, storage space could certianly be an issue. It's also insecure, as admins are unable to control browser configs/add-ons, etc.

    If I were an admin in that situation, I'd reject the use of Chrome altogether on terminal servers. And if anyone really needed Chrome (although why anyone *needs* Chrome is beyond me), they can disable screen locking on terminal servers altogether and use App virtualization [wikipedia.org] or VDI [wikipedia.org].

    As I mentioned in the comment to which you replied, those were just the two things that came off the top of my head. The above are a couple more. I'm sure I could come up with a long list if I had a need to solve this problem. I choose just not to use Chrome at all instead.

    --
    No, no, you're not thinking; you're just being logical. --Niels Bohr
  • (Score: 3, Interesting) by Popeidol on Saturday November 16 2019, @04:48AM (2 children)

    by Popeidol (35) on Saturday November 16 2019, @04:48AM (#920890) Journal

    It allows for this, and last I checked this is the default install option if the account does not have admin rights.

    Also of note: At least in group policy, chrome allows admins to disable auto-update and roll updates on their own schedule. I started doing this a few years after an auto-update broke access to some internal tooling. I'm not sure if they have the same option via other distribution mechanisms.

    • (Score: 1, Informative) by Anonymous Coward on Saturday November 16 2019, @07:35AM (1 child)

      by Anonymous Coward on Saturday November 16 2019, @07:35AM (#920921)

      This wasn't an auto-update, it was pushed through some sort of otherwise-un-announced alternate channel. It even effected the previous version of chrome (77) so rolling back didn't save them.

      • (Score: 2) by Popeidol on Saturday November 16 2019, @06:06PM

        by Popeidol (35) on Saturday November 16 2019, @06:06PM (#921016) Journal

        Looks like I jumped the gun while replying: the situation described is kinda fucked for sysadmins and they have no easy way to avoid it

  • (Score: 0) by Anonymous Coward on Saturday November 16 2019, @06:24AM (1 child)

    by Anonymous Coward on Saturday November 16 2019, @06:24AM (#920902)

    Web browsers are the most frequently used applications on the planet. A gigabyte for that purpose is nothing, even on a 16 GB system.

    • (Score: 4, Insightful) by maxwell demon on Saturday November 16 2019, @06:46AM

      by maxwell demon (1608) on Saturday November 16 2019, @06:46AM (#920907) Journal

      Quite the opposite: Web browsers are almost always run not as main application, but as side application in order to look up things. That means it should steal as little memory as possible from the main application.

      --
      The Tao of math: The numbers you can count are not the real numbers.