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? ;-))
Related
Hi I'm getting the error
Error creating WebGL context.
Uncaught TypeError: Cannot read property 'getExtension' of null
This is happening on google chrome 71 but I find it odd because if I open up dev tool and refresh the page it works perfectly fine I'm at a loss to what is causing this any idea's ?
It's worked perfectly fine untill today nothing has changed on the PC or browser. My drivers are all up to date, webgl is enabled...
if you have two GPU installed on your system you might want to try to enable
Override software rendering list
in chrome://flags/
I'll leave this here for anyone else apparently it's a browser and graphic card issue
mrdoob: The graphics card is only one of the reasons why the context
can't be created
https://github.com/mrdoob/three.js/issues/4927
This seems to be why unless anyone else has any other ideas...
The issue is on going and not fixed it would be interesting to know why this happens though and why opening dev tools and refreshing resolves the issue for me.
EDIT-
Apparently for me this was due to my graphic card being blacklisted because it's old.
The fix for me was manually enabling WebGL acceleration under Chrome’s feature flags: chrome://flags/
I have encountered this several times with THREE.js. It arises for me once memory resources are shared, abandoned, or overwhelmed, for example:
I have a good render loop but then I introduce long tasks.
I perform extensive, continuous testing. As I modify live settings in Chrome Inspector, THREE does not reflect all changes without fail. Memory may not be released until I restart.
I leave the program running overnight. The next morning the browser is froze, black, OOM...
I use multiple instances of a resource, for example
Web Audio and Magenta Music. The quality may perceptibly degrade and
throw its own errors, but... I will also encounter worse silent
errors. For example when I also steam music in another tab, or click
audio/video media on Twitter... frozen browser, black screen, WebGL
context loss.
I just wanted to comment that I saw this due to other unrelated errors in my app that got thrown first.
I updated my graphic drivers (NVIDIA) and didn't restart chrome nor the PC, and was having this issue.
I just restarted the PC and now it's fine.
This was resolved for me by simply installing the latest and restarting my browser - thought I'd add it here to hopefully save some future soul from wasting an hour like i did.
Error creating webGL Context in three.js.min ver 93
I had the same problem with Chrome version 104.5112.102 and managed to fix it by going to Chrome, Settings, and switching off the
Use hardware acceleration when available.
the graphics card is an old GE Force 8600 card running on Windows 10.
For me, I restarted my computer and the error did not appear again. You can try doing this before you do anything more complicated.
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.
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).
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.
With HTML5's offline capabilities is it possible to create an app that will persist after the connection is lost and the browser is closed? Specifically, here's what I'd like to do:
Connect to the app while online. Download the entire app including a small database it runs on.
Close the browser and disconnect.
Open the browser again while offline and load the app from the local cache.
Thanks to Mark Pilgrim's excellent book I believe I have an idea of how to accomplish the first step, I'm mainly wondering if the last step is possible. If this is possible, I'm guessing it requires some configuration of the browser. Any settings I should be aware of that aren't obvious?
Thanks very much for any help offered.
The last step should be possible - it just depends on what extent you want to implement it to. To my knowledge it shouldn't require any browser settings. You just have to be aware of the limitations of local storage, which I believe is 5mb max at the moment (for most browsers). Obviously you'd have to perform the checks for such permissions as outlined int the Dive Into Html5 guide you linked.
The quickest and dirtiest way is to simply issue a GET request to your online app. If it responds correctly, then use the online version. If not, use the local cache. Just disguise the timeout/failed response as a 'loading' screen.