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: 2) by sjames on Saturday November 16 2019, @07:36AM (2 children)

    by sjames (2882) on Saturday November 16 2019, @07:36AM (#920922) Journal

    ....and at least *some* shared state data (cf. %PROGRAMDATA%) changes to which impacts all users of a terminal server.

    That's so crazy I didn't believe it, but it appears you do understand correctly. It makes sense to share code and read-only initial data, but to share read/write is begging to leak data. I can't imagine a single reason why Chrome would ever use publicly shared memory for anything and I certainly hope Windows or Citrix didn't decide on it's own to make memory publicly shared.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by NotSanguine on Saturday November 16 2019, @10:42AM

    by NotSanguine (285) <{NotSanguine} {at} {SoylentNews.Org}> on Saturday November 16 2019, @10:42AM (#920944) Homepage Journal

    I certainly hope Windows or Citrix didn't decide on it's own to make memory publicly shared.

    That's a great point. I can't confirm, but I suspect that it's more likely that some shared setting in the Chrome configuration in %PROGRAMDATA% is triggering this behavior. Given that Chrome also maintains per-user configurations in %USERPROFILE%, it should be a pretty easy fix in Chrome.

    It's *almost* enough to get me to read TFA to see if they discuss this at all. That said, it seems pretty stupid of Google not to consider the terminal server use case in dev/testing.

    Something in TFS enhances my suspicion that's it's a Chrome issue, rather than a Citrix/Windows issue:

    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.

    If Chrome trying to reduce battery drain/resource utilization, that makes sense for laptops/tablets/phones. It is, however, completely irrelevant (and as we see, detrimental) in a terminal server environment.

    After initially rereading the bit from TFS above, it seemed to me that Chrome should look at the configured power plan [windowscentral.com] (and admins should set it appropriately for (terminal) servers) and only enable such power/resource-saving features when it makes sense for the configured plan.

    --
    No, no, you're not thinking; you're just being logical. --Niels Bohr
  • (Score: 2) by driverless on Sunday November 17 2019, @03:05AM

    by driverless (4770) on Sunday November 17 2019, @03:05AM (#921158)

    Google's apps have always been pretty much all-elbows, we control the system and will do whatever we want. Years ago I wanted to install Picasa for my parents to sort their photos, and it assumed the user was admin (i.e. my elderly parents were Windows system administrators on their PCs), shat all over system directories, and when run as an ordinary user (after installing it as admin) segfaulted on startup. There were forums full of complaints about this, Google's response was basically "meh, not our problem, just run everything as admin".

    Come to think of it, that approach is pretty much Google all over, we control things and will do whatever we want.