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.
Related
I have recently discovered the Mac OS X application GeekTool where one can use a html file as your wallpaper. However that isnt the most interesting thing, what I find interesting about it is that it keeps the html file alive even allowing http requests. I wanted to create that using Node.js and some other web technology that allows to run a browser on the desktop with full access to nodejs' APIs.
So I wondered if there is any way to create an alive browser in the background (as a wallpaper), which is interactive (e.g. I can press buttons and type in inputs). If so, where can read about that?
I prefer either one of the packages mentioned above, but others are accepted as well. What I need it to do is just being under the desktop-icons but as well over the default wallpaper, so it can be interactive.
Thanks 😀
I'm running Selenium grid with only Windows machines and the resource use is quite high.
I've been toying with the idea of putting Chrome and Firefox inside docker containers to improve efficiency.
My question is are there any key differences in the browsers themselves on the different platforms, i.e. would Chrome on Windows behave differently to Chrome on Linux or do they run the same code and behave the same?
Selenium tends to mock the User Actions and some among them are:
Sending Text : sendKeys("LiamHarries")
Special Keyboard Characters : sendKeys(Keys.ENTER) and sendKeys(Keys.RETURN)
Mouse Hover : moveToElement(element).perform()
Click : click()
All these User Actions are independent of the underlying os and Hardware Configuration. Hence if they run the same code and they will behave the same.
Update :
As per your comment ...if something is rendered one was on chrome on windows will it be the same on chrome on Linux..., it is worth to mention when new versions of Web Browsers are published in different formats (e.g. .tz/.tr/.gz for Linux and .zip/.rar for Windows) and they contain the required components (separate for windows / linux and 32 / 64 bit) to install the Browser as per underlying OS Architecture.
Though the install location and directory structure may vary within the os , the release candidate WebDriver goes through different Testing Procedures (e.g. Alpha Testing, Beta Testing, UAT and UX Control Testing) which does ensures that the User Experience is seamless and similar across all OS Variants.
Hence, from Selenium's perspective underlying hardware bears no impact
Note : There have been instances when the Headless Chrome feature was available in early Google Chrome builds but that was a well planned move following the Chrome Release Map
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.
TLDR: Can the Chrome Bluetooth API be used on the Windows mobile platform?
I'm on a quest to find a solution for bluetooth connectivity across various platforms.
We plan on having native iOS and Android versions for our app, and a web app for other platforms (limited time and budget).
The setup of our product requires a one-time bluetooth connection to configure a wireless connection if necessary. This is fine for the iOS and Android versions of the app, but presents a problem for desktops/laptops or Windows mobile users.
The option for our device to act as an accesspoint has been considered, but it's not a very user-friendly solution. It needs to be easy enough your grandmother can set it up, and switching to another wireless network doesn't qualify.
In my research, I've come across the Chrome Bluetooth API available in Chrome Browsers starting in version 37. I'm wondering how accessible this would be for, say, the Windows mobile crowd. Or laptop and desktops running Windows, ChromeOS, etc.
Thanks in advance!
First, that api is not available to the web, it is available for Chrome Packaged Apps, which are published to and installed from the Chrome Web Store (they do not have a URL you can just visit).
Second, I do not think that Chrome Apps are available for windows mobile, though they are supported for all the desktop platforms. (Make sure that the bluetooth api support you need is fully support across all platforms, though, since there are some limitations).
Finally, there is ongoing work for an upcoming web-bluetooth api which will be available for the open web -- but that is some ways away.
Best of luck.
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