Closed mcodyre closed 4 years ago
issue-label-bot[bot]
commented
4 years ago Issue-Label Bot is automatically applying the label bug to this issue, with a confidence of 0.59. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!
Links: app homepage, dashboard and code for this bot.
qnixsynapse
commented
4 years ago I have personally yet to encounter this bug but since this bug is been reported in Redhat Bugzilla as well, I need to investigate this.
qnixsynapse
commented
4 years ago qnixsynapse
commented
4 years ago Fixed upstream. Closing this.
Steps to reproduce the problem: 1.open browser 2.wait a couple of hours 3.see attached jpeg
What is the expected behaviour? it doesn't attempt to auto update
What went wrong? it attempts to auto update and the device is running in kiosk mode without user interaction to remedy the issue (not using the kiosk switch just full screening the window)
Did this work before? Yes 73.x.xxxx
Does this work in other browsers? No Chromium-vaapi auto update attempts to run in Linux on version 76.0.3809.132 as well
Chrome version: Chromium-vaapi 75.0.3770.142 Channel: n/a OS Version: fedora core 29 Flash Version: none
Things we have tried so far:
We have set: "DeviceAutoUpdateDisabled": true,
In a policies file in /etc/chromium/policies/managed/engine.json. Although it still prompts an update.
We are going to try today: Install chromium-vaapi fresh without an active network connection to see if this occurs.
I have created a firewall that blocks all outgoing traffic although it still gets into this state. I believe chromium may be keeping a file that indicates that it needs to update that it pulled from the network. We use a new random user directory every time chromium starts so I'm not sure how it would hold state. --user-data-dir=/
I've attached an image of what we are seeing.
Thanks
Mark