I was till last month using Chrome Browser for testing the screen share feature using WebRTC API. For doing this I enabled the flag "Enable screen capture support in getUserMedia()" in chrome://flags.
Now with recent update of the Chrome Browser, this flag is no more available and most of the other WebRTC flags are disabled. I checked with even Chrome Canary and the result was same. The flags are either missing or disabled with message "Sorry, this experiment is not available on your platform.".
I am neither able to revert to older chrome version.
I would appreciate if anyone can give me a clue as to how enable the above flag for screen capture?
Thanks
You cannot use those flags any longer and there is NO WAY to access them again short of rolling back your update. They were removed for security reasons. Now, you have to use a chrome plugin to do any desktop capture. Which is frustrating but the only way and it is fairly simple.
Here is an another SO question that should give you direction.
Firefox also now has screen/window/etc capture. For now, for similar reasons to Chrome, we've put access to the feature behind a whitelist (though an extension could extend the whitelist as well; we haven't prototyped that yet).
See http://mozilla.github.io/webrtc-landing/gum_test.html (In Firefox 33 or later - currently that's Beta; no attempt to polyfill was done there as it's an internal testing page).
Related
Originally posted here.
I was under the impression that WebGL should work on Chrome on pretty much any desktop device, but that it may fall back to software rendering in some cases (assuming you don't pass failIfMajorPerformanceCaveat=true when getting the context). However in practice this seems not to be true for a substantial number of users on both Macs and Windows (especially, but not limited to, those within some kind of managed corporate IT system).
As far as I can tell, on all hardware/setups where WebGL is disabled in Chrome, it is possible to run it using a different browser (FF, and even IE11). I believe that IE11 only uses software and FF may be less strict with its blacklisting of GPUs, but that doesn't explain why Chrome can't switch to software when hardware is unavailable. Indeed, in some cases, overriding the GPU blacklist in Chrome does seem to work (but presumably is not a good idea).
So firstly, could I check that my assessment of the situation is correct? And secondly, could anyone suggest how to force software rendering (i.e. flags etc.) and/or point me at an issue discussing this?
Any advice would be very much appreciated - even if the process is rather involved it is still worth knowing about as it may be workable for our clients.
update:
#gman points out that there is no software emulation on Macs in Chrome, but that still leaves the question of what's going on in windows.
update 2:
(to partly answer my own question): it seems that (at least on 32bit Chrome on windows) if you go to chrome://components and see SwiftShader is at version 0.0.0, then simply hitting the update button should download the latest veriso,n and hey presto..it works. Not sure about 64bit Chrome though.
update 3:
As #Nicloas says, M59 in Chrome (to be released in May/June 2017) should fix this issue in Chrome on Windows and Linux, with Mac following later.
Quoting my own answer from swiftshader#googlegroups.com:
I'm happy to let you know that with the upcoming M59 release of Chrome, we have integrated SwiftShader to provide seamless fallback support for WebGL in case the GPU is blacklisted.
We were previously only using SwiftShader as a separately downloaded component, which indeed does not work on managed corporate systems, and required a browser restart. Integrating SwiftShader was only possible after open-sourcing it and substantially reducing its binary size.
You can test it today on Windows using Chrome Canary or the Beta channel, and specifying the --disable-gpu launch flag. Linux is also supposed to work but the libraries were mistakenly not shipped as part of the beta package, which we hope will be rectified in the next update and before it reaches the Stable channel. We haven't started integrating Mac OS X support yet, because Chrome works significantly differently there, but it's on our radar.
So i have the following problem.
Any time i click on a request to view the headers/payload/response
i receive a not responding window.
If i wait ~2 minutes it works.
So what i receive here is a developer tools not responsive status when working on local machine.
I tried to re-install chrome. Nothing changed.
Current Version is: Version 50.0.2661.102 m listed as up to date.
Is there any possibility to get some logs or did anyone faced the same problem?
I think it can be relevant if i show what extensions i have installed.
But i tried to enable/disable them and nothing changed.
And i get the same comportment in incognito mode too.
Later edit: I somehow identified the problem. Idea is that chrome is trying to display the cookie (request headers) which was 18k characters long and it looks like this is slowing a lot developer tools and sometimes make him crash.
I just saw that in Mozilla cookies are limited to a couple of characters (display perspective) and after that they show ...
I can't find any known issues regarding this crash, so here are a couple of steps you could take:
Use the Chrome Cleanup Tool and see if that helps.
Fully clean and re-install Chrome (including deleting user folders). If it works after that, you can slowly add extensions and plugins back and see if any reintroduce the problem.
As of now all the chrome browsers version above 40 are coming with disabled NPAPI plugin and it's going to permanently block the support for it. I have a silver light control in my application and am going to to rewrite the functionality with others but temporarily I want this NPAPI plug in to be auto enabled when web application launches in client machine. Is there any way so that I can auto enable NPAPI plug in in chrome through java-script or jquery or is there any other way I can load silver light controls in Chrome browsers without manually enabling it? TY
No. That would kinda defeat the whole purpose of what they are trying to do.
The closest you could come would be to manually edit the Local Setting json file in the Chrome profile to add the enable-npapi flag, but that would require an executable or installer running on the client machine which would only work if Chrome wasn't running.
The Chrome team has obviously determined that nobody actually has a good reason for using NPAPI, or at least that those reasons aren't good enough, and therefore any of us who rely on it are now required to find another way.
(Frustrated? Me? What ever gave you that idea? ;-))
I’m using the AppCache in order to enable offline access for a web app. The issue is that for development every time I make a change to my JavaScript I also need to make a change to the manifest (in order to trigger a re-download of the cached field). Now I know that in FireFox you can disable the AppCache (in fact you are prompted when you first visit the page whether to grant permission to web site to store data locally) which makes it a lot more convenient for development.
My question is there a similar option for chrome and safari?
I know that I can view/Edit the AppCache in chrome via chrome://appcache-internals/, what I’m looking for is a way to disable it.
Thanks
In Chrome, use Incognito Mode. Okay, it's probably not what it was originally intended for, but it does the job. Nothing gets cached, and now developers everywhere have a handy excuse for why they might be using Incognito Mode.
I assume there's similar 'Private Browsing' functionality available in Safari.
EDIT: I see from your comment that you want to disable Cache Manifest functionality only. Try starting Chrome from a Command Line with the --disable-application-cache switch.
We have several FogBugz customers who have reported an error in Chrome where if the user presses Enter in an edit box, the edit box will lose focus and they'll have to click back in to the box for it to gain focus.
All users reporting this error (that we're aware of) have mentioned using Chrome Beta. We don't support Chrome Beta, so we advise downgrading to Chrome Stable. We can't repro the bug on Stable.
One of our users uninstalled Beta and installed Stable. He tried again and was again able to reproduce the bug, even after clearing his browser's cache (with no tabs open) on Stable.
In a related scenario, another member of our team noticed quirky behavior in Chrome persisting when switching from Chrome Dev to Chrome Stable. He also cleared his cache and noticed the behavior persisting in Chrome.
Have any other web developers experienced this kind of behavior in Chrome with customers using their web applications? If so, is there anything you can do within your application to help users and/or do you know of a way to completely "wipe" Chrome and revert it to the Stable version? (at the moment, the latter option is preferred).
Moving up versions should be okay, since Chrome is designed to upgrade smoothly.
Moving down versions (like dev to stable) can be problematic, since there's really no provision for older versions of Chrome to understand new versions of the user directory.
If you want a fresh start, you can wipe your entire user data directory. However, since this directory contains everything about the user (caches, saved passwords, apps/extensions, etc), all of that will be lost.