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.
Related
As my application only support Chrome browser and try to test it using IBM RFT.
Issues:
Browser enablement test is fail while testing Chrome from Enable Environment in RFT
Due to that not able to capture any objects in Chrome using RFT
Tried the below steps as well but not able to resolve :
https://www.ibm.com/developerworks/community/forums/html/topic?id=1e5ec381-03c3-4ab6-a9b8-4ce98f592b3b
If anyone face the same issue previously please do reply.
If you are using Chrome 45(Where NPAPI is disabled ) or above , you need to install RFT 8.6.0.5 on top of which a test fix is available that will allow you to execute/playback your existing scripts. To get the testfix you will need to contact the product technical support.
Rational Functional Tester old versions doesn't work with Chrome anymore. In their last release notes (fix pack 4) the greatest "feature" is to make it work with newer versions of Chrome. I have the version just before this one and I guarantee that it doesn't work with Chrome. The update process is really error prone. Reserve at least day to do it.
Some websites claim to 'not support Linux', but appear to work fine when I browse them from a Linux box. One such site refuses to allow me to log in when my User Agent String advertises that I'm running Linux, but works perfectly fine when I use the User Agent Switcher add-on in Firefox.
What features of a website could be OS specific?
If a website is designed to work on a particular browser, should it work on that browser regardless of the underlying OS?
This SO question suggests that rendering may be platform dependent. Is it likely that rendering differences would be significant enough to make a website unusable under a certain OS?
Are there more fundamental ways in which it could be OS dependent?
The website should look fine under same browser version in various OSs. There are things like location services that can be disabled on your OS completely, or java and flash applets but mostly they are cross-platform.
Howerver, a shining example is Silverlight that is not supported on Linux so pages relying on it (e.g. Netflix) will not work on Linux.
Mostly its just laziness of staff to test website on linux and thus they simply state that its not supported to avoid complaints from users.
With IE 10 testing my website on older versions of IE was very easy and always worked as it should, I just went to the developer tools, picked the version I wanted from the menu and I had no problems.
Now, after upgrading to IE 11 I encountered some problems with this method of testing. First, stuff I put inside HTML comments like <!--[if lt IE 10]> don't show anymore. Second, the same website that I tested a few days ago on older versions of IE with IE 10 looks very different when doing the same tests on IE 11.
So, why do all this stuff happen and how can I solve it?
Internet Explorer 11 shipped with a fairly good set of emulation tools. If you know what issues are being reported in Internet Explorer 10, you can attemp to replicate those in emulation. If you succeed, it's very likely that you can proceed to troubleshoot those issues while in emulation.
At times you may run into some things that aren't reproducible in emulation, and instead require a native instance of Internet Explorer 10 (or any other version for that matter). At this point you really only have a couple of options:
Virtual Machine in your browser (http://browserstack.com)
Virtual Machine on your desktop (http://modern.ie)
Each option has its own set of pros and cons. In-browser virtual machines can be spun up very quickly, and don't require a serious amount of system resources to run. That being said, the experience can be choppy and not conducive to troubleshooting issues that rely on low latency.
Desktop emulation is great because you have a more near-native feel. Unfortunately, this means you need to download very large files to get a second operating system running within your current operating system. Furthermore, you may find yourself wrestling with configurations and more.
I personally use a combination of the two, depending on what issue I am presently trying to troubleshoot. As a good practice though, writing clear and valid markup, along with using best practices like progressive-enhancement, and feature-detection to serve up alternate code-paths, results in a lower chance you'll have to spend much time debugging anything.
The latest ie11 have functionality of like previous ie browser version.
1 To access the modes, start the F12 Developer Tools,
2 click the Emulation icon at the bottom, and choose a Document Mode — they’re not named “browser modes” any longer
This article may help you.
http://www.sitepoint.com/ie11-browser-modes-return/
I had users complaining about issues in IE10, and was not able to recreate them in IE11 using F12 emulation. What I ended up doing (after many attempts to uninstall IE11, and install IE10 to no avail (in Windows 10)) was this:
Download VirtualBox here: https://www.virtualbox.org/wiki/Downloads
Go to: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
Download the VM you want to test with and then load it into VirtualBox. There are instructions on their website on setting options etc. Mostly you need to set memory, and virtual hard disk location and size. I used 1024MB and the default for the drive, since I am only running IE with this VM. It worked great. Networking by default put the host at 10.0.2.2 so my localhost test website running on localhost:8080 was at http://10.0.2.2:8080// on the VM. It worked well.
Hope this may save someone some time.
The emulation missed two different bugs one with Array.filter, and another with __definegetter__.
The VM picked these up. It is a slower approach than emulation.
Just saw the "On IE11." Sorry about that - still this is my recommendation. And you don't have to uninstall IE11.
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.
If Microsoft's method for using IE as a local host for HTA's then, can I use any other browser instead?
You can't.
There is a similar Mozilla project named XULRunner, but HTA only works in Internet Explorer - the two technologies aren't compatible.
To make this clear: HTA will probably not work in anything that's not IE. Yes, HTA is a browser control in a window, but it also has normal aplication privileges (i.e. filesystem access, registry, arbirary code execution etc.). When running in a browser, these privileges are denied (for good reasons - you don't want just any webpage to read your files).
So, launching the HTA in a browser will work, but any interaction with the local system will fail, which negates the whole idea. Launching a HTA in XULRunner will also fail, because XULRunner uses a completely different API.
The only scenario that could possibly work is this: a webapp which doesn't use any of the HTA-specific or XULRunner-specific API (i.e. behaves like a normal browser app). In such case, your app might work with HTA, XULRunner, as well as in any browser. Incidentally, this would take away any advantage of using HTA and introduce masive security holes because of the higher privileges; you'd be better off with using Google Chrome or Mozilla Prism for that.
(We've been trying to find a cross-browser solution for some time, and HTA is definitely not it)
I was tackling the related task of running hta's from various browsers. I've put my findings here for anybody else who is trying to do that and finds this question.
You can run hta's from several browsers, using the same mshta executable that IE uses. You need fully qualified URI's in your hta code, which isn't needed from IE.
Today (2011-02-01) I tried using hta's from Firefox (3.6.13), Opera 11 and Safari for Windows 5.0.3.
After some teething problems in Firefox I got hta's to work from those browsers. (In all cases these use the same mshta executable that IE uses. This is not hta's running in other browsers, but running hta's from other browsers. This might suit your purposes.)
The hta started desktop applications on my machine (as it does from IE).
The experience wasn't perfect. For IE I set root relative paths in the hta. For the other browsers you can't do that. You need to set fully qualified URI's for things like images, referenced hta's and icons.
So after a little editing I have the hta's working from 4 browsers (IE 8, FF 3, Opera 11 and Safari 5 (Windows)).
(Quick snapshot of that. I'm running hta's from a web server on the local machine. (I have no plans to run them from remote sites.) This allows my workflow to go from browser to desktop more smoothly. The hta's fire up local applications that do things like edit web pages (including the hta's themselves), validate those pages and fire up IDE's. Bridging the gap between browser and desktop apps. has been a liberating experience. I recommend it!)
Notes:
The Firefox development team have notes about enabling hta's which encouraged me to continue after initial failure.
To achieve this in Firefox configuration I set HTML applications to run under mshta.exe (called Microsoft HTML Application Host, in the combo box). Initially that didn't work. I selected "other" picked the same application by hand. That worked, though I have two identical looking entries! You need mshta.exe on your machine to run for any browser. I assume the normal way to install mshta is with IE. (mshta is essentially a modified version of IE, possibly not the current version!)
The Firefox developers have marked this as a strategic effort to dislodge IE from the Enterprise. Their implementation (and Opera's) force you to use fully qualified URI's but apart from that the hta's work as expected.
Firefox seems to cache old versions of the hta's, and doesn't download new ones, though it appears to download something! You might need to clear the cache during development.
My first attempt to do it with Chrome was not successful. Further investigation suggests Chrome doesn't have a native interface for invoking other processes, based on their file extension.
It isn't so much that IE hosts anything, but that mshta.exe hosts components it shares with IE. MSHTA is a script host, much as CScript and WScript are. While IE is also a script host (in the strictest sense) its primary purpose is to be a Web browser.
The Mozilla project mentioned previously is the closest alternative I have found that is based on a browser's innards.
Other script hosts exist for windows too. One of these is NS Basic/Desktop but it is based on standard Windows controls, not browser rendering and an HTML DOM.
Just to be clear: It is not IE nor MSHTMA that really renders a webpage. The rendering thing is partly build into the OS. Thus, things like Active Desktop (does anybody remember that XP thing?) or .HTA or .CHM work without IE. It's just the same way to recognise some HTML things.
I believe Internet Explorer's hosting of HTA apps works because their HTA host is registered to handle the extension. If this is indeed the case then in theroy another host could be used
For the sake of completeness I should note that I am not expeirienced in the development of HTA applications and am basing my response on my understanding of the Windows OS