I'm experiencing a strange issue.
When I open Chrome 40 I get very CSS3 smooth animations. After some arbitrary number of animations or page reloads, animations start to decrease their FPS (i.e. frames per second) until they become absolutely broken (no animation).
If I reboot the machine, the issue is solved for some time until it happens again.
Furthermore, I've verified GPU acceleration is ok reviewing chrome://gpu status page, and it's everything ok excepting it warns about the following issue:
Some drivers are unable to reset the D3D device in the GPU process
sandbox
I've also tried this on Chromium 42 and it's not having the issue, but because I'm developing an Apache Cordova app and I'm using Apache Ripple to work on app's layout, I need also --disable-web-security flag on Chrome to enable cross-origin AJAX requests to get the same behavior than the actual app on Android, and Chromium 42 accepts the whole flag, but it has no effect, thus I still need to use Chrome.
Does anyone experienced this issue and has solved it?
Also...
I've also tried to update to Chrome 41 beta and I get the same issue...
Related
General Problem
We've had a long-standing problem with our two ExtJS 5.1.0 apps that div scrollbars don't show in Chrome, using only our QA testers' AWS Workspace Chrome browsers. They don't see this in other websites using that Chrome, only our two applications. We've been able to ignore this since the problem was isolated, but now a user is having the same problem.
We've been able to confirm that the difference is that wherever there's a div that should be overflow: auto is being generated as overflow: hidden. So scrollbars for grids, dropdowns, etc don't render but the div can still be scrolled via other means (tabbing, page down).
I've been looking for general ideas about what could cause this--is it ExtJS? Windows setting? Chrome setting? Again, the problem is isolated to AWS Workspace's Chrome and a user's Chrome.
Versions
Chrome:
AWS Workspace has exact same Chrome version as me, 79.0.3945.88.
User has Chrome 80.0.3987.149 (up-to-date).
Windows:
AWS Workspace is Windows Server 2016 Datacenter.
User has Windows 10.
What We've Tried
These are all troubleshooting steps we've tried in the AWS Workspace Chrome:
Disabled all extensions. Also ran in incognito mode which should do this also. The extensions are nothing that I don't also have, and I don't see the problem.
Inspected Chrome's flags--they're all default, and again not different than what I have.
Disabled Chrome's “Use hardware acceleration when available” setting and restarted Chrome.
Previously opened a ticket up with AWS and they were unable to help.
Researched any connection of this to Chrome, ExtJS, or Windows Server 2016 Datacenter without luck. Only found general information about "what to do if you have scrolling problems in Chrome".
Other Problems Our Apps Have in AWS Workspace Chrome
Listing these in case it helps trigger any ideas about the underlying problem, but focusing on the scrolling for now. Again these are isolated to Chrome in AWS Workspace (unclear if the user is seeing these also):
Drag and drop doesn't work.
Tabs that aren't the selected tab when the tab bar is loaded don't load at all.
It turns out that the problem was related to touchscreens. Our user has a touchscreen laptop (and didn't realize it for a while, we asked about this early on). And the Amazon Workspaces are touchscreen-compatible, as they have a "HID compliant touch screen" device listed in Device Manager > Human Interface Devices. So something about touchscreens + Chrome/Edge is telling ExtJS 5.1.0 that the device is mobile and scrollbars shouldn't be rendered.
Solutions:
For our user, she was happy to disable her touchscreen device and this worked for her.
For Amazon Workspaces, disabling the touchscreen device did not work. For Chrome we were able to resolve by adding --touch-events=enabled to the Chrome shortcut. There are various touch-related Chrome flags mentioned online as a solution, but none of those are available in the current version. Anything touch-related we did find in Chrome's list of flags didn't help.
I haven't looked for a solution for Edge if someone uses Edge and wants to keep their touchscreen. This is fine for us right now. (Because we realized Edge has the problem also, presumably due to Chromium. Did not see it with Firefox.)
And I did confirm using ExtJs' Kitchen Sink examples that I can replicate the problem in 5.1.0 with both a touchscreen laptop and an Amazon Workspace. Also that I can't replicate the problem in the current version, so we should be good once we upgrade.
I am running Node.js on localhost:3001 and unintentionally wrote some code with an infinite while loop. This locked up Chrome to the point where the only resolution was to kill the browser. Since then, I found the problem in my code using Firefox, and fixed the code, but even after restarting Chrome, it will not load my page. I even changed the port that the server runs on, and the cache is disabled with developer tools open - Chrome simply refuses to load the page. I see a single request to the server for the page, but in Chrome it just registers as Pending.
Has Chrome maybe flagged this page as suspect, somehow? How do I get it to play again? I would at least expect Chrome to offer some opportunity to kill a tight loop - like Firefox does - but I've yet to see it. Is there some setting I can tweak? I'm on version 74.0.3729.169 (Official Build) (64-bit), although now that I opened the About page, I see that it is updating Chrome, so maybe that will fix it.
UPDATE: It didn't fix it, but it works in Incognito mode. ???!!!
UPDATE: Disabling all of my extensions also didn't fix it!
I found a setting in Chrome: "Continue to run background apps when Chrome is closed"
I turned that off, and now it works again.
When i wrote the code 6-7 months back everything was working, with no issues what so ever. But recently when i tested it, In Chrome specifically video freezes after some time.
Calling from Android implementation.
Call is working fine in firefox, safari.
If both devices are on same broadband, the issue happens about 1-2 minutes later, if anyone on 4G or cellular it happens instantly. My best guess is that chrome skips one frame to encode, and the drops all coming frames.
Here is a screenshot of webRTC internals sending video graph, after it dropped, you can clearly see the drop in 'sending bytes' and 'constant line' in encoded frames.
I don't even have any idea about how to debug this, any help is very appreciated. Thanks
How does the peerconnections iceconnectionstate look like? Does it go to disconnected and (after some time) to failed?
See https://testrtc.com/webrtc-api-trace/ for an explanation for that part of webrtc-internals.
I faced the same issue and as far as I know, this is a bug in Google Chrome version 56 and above. You can try downloading Google Chrome version below 56 it will work on the downgraded version. There are numerous bug reports filed with this bug and the interesting part is it is reproducible on Android's Google Chrome Application with version 61 and above.
Check out the following bug reports.
video Freezes on Google Chrome
Android Chrome 61, video freezes after connecting
Chrome 61 on Android 6.01 or 7.0 Received Video Freezes
Video freezing issues
When Chrome stops WebGL and gives you the following error (in a yellow banner on top of the screen): "Rats! WebGL hit a snag...", and reloading does not work (WebGL is still not re-enabled), is it possible to re-enable WebGL without restarting Chrome?
Context:
Chrome disables WebGL probably because it requires too many resources: I ask it to display 400,000 billboards on Cesium, for those who know what this is.
I know how I could reduce the resources my app asks for, but actually I am exploring its limits for testing purposes. So I am going to make Chrome disable WebGL a lot of times, and I do not want to restart it everytime it disables WebGL.
My configuration:
Chrome 35.0.1916.114 m
Windows 7 Pro 64 bit.
Solutions explored:
I already tried to open a new Chrome window, it does not work. For the moment all I can do is close all Chrome windows and restart it.
I already tried to put --ignore-gpu-blacklist in the Chrome shortcut (even if I understood this is for Windows XP, right?).
Hope I was clear enough.
Thank you for your help.
I was having the same problem and I just found a solution. It sounds like this didn't work back when this question was posted but, it works now!
Refreshing the page doesn't work. If you clicked a link from a different tab to open the tab the crashed, clicking that link again doesn't work. You have to open a new tab and paste in the URL of the page that you want to reload.
I'm guessing this is due to chrome threading... by opening a brand new tab, you create a new thread instead of using the existing one.
In your application you should properly handle webglcontextlost and webglcontextrestored events. In particular, you should prevent default event action in webglcontextlost handler thus telling the browser that you can restore proper functioning of your app when webglcontextrestored will be fired.
Today google chrome updated to last version, before that update the website was working without any problem. It's working on firefox and internet explorer without any problem though.
What's wrong with google chrome ?
http://www.mersin-mezitli-satilik-daire.com/3-boyutlu-sanal-tur-mersin-mezitli-satilik-daire.php?iframe=3&anasayfa=1
This issue may be caused by the dreaded 'Pepper' Flash Player, which has also been breaking Flash content for me in Chrome.
I don't know what the solution is for your broader audience of Chrome visitors, but to fix the problem locally:
In a new tab, go to the URL: chrome://plugins/
Find the entry for 'Flash' and expand [+] Details if not already expanded
Look for the entry where the location of the plugin ends: ...PepperFlash\pepflashplayer.dll and click 'Disable'
You will hopefully have at least one other instance of Flash Player installed (if not, try installing a debug player from Adobe's website), and enable one of these.
I should mention, the Pepper Flash Player seems to regularly re-enable itself, possibly whenever Chome auto-updates itself, and I find myself having to repeat this process every couple of days.