It is possible to change the JavaScript engine being used inside a Web Browser?
Some additional information:
For testing mobile applications, I would like to be able to emulate the exact JavaScript engine being used by a web browser to find bugs.
If there anyway to change the javascript engine being used in a Browser such as Chrome or would I need to build my own browser?
This is an interesting feature. I'd like to test Safari Javascriptcore engine in Chrome browser instead of V8. Because I noticed that some of my angular code is not rendered correcty on JavascriptCore engine and rendered correctly on other browsers. It'll be in handy when you found some bugs on ios devices and you have no mac device nearby.
UPD
I found browsers where you can change browser engine lunascape and avant. these browsers are triple engine browsers and you can switch between engines.
There are a number of open source browsers. It is theoretically possible to replace the JavaScript engines they use and compile your own executable. Indeed a number of browsers have changed engines during their history.
You'll probably need to make changes to the API to make them compatible though.
There's no way to do this from JavaScript, of course.
Generally, a given browser ships with a single JavaScript engine. There is no need to ship with multiple engines, because if additional features are required of the engine, they'll simply be added to the engine which the browser ships with.
I could potentially see the existence of a modular web browser which requires plugging in a JS engine separate from the main program (which could then result in the user having multiple JS engines on their machine), but I know of no such browser, and thus know of no means by which JS could be used to swap the engine.
I suppose you could implement EMCAScript in JavaScript, but that seems like a tremendous hassle.
In response to the edits to your question: I believe Chrome Dev Tools' mobile emulation will get you what you want instead of what you've asked for.
Related
Most cross browser testing tools test for layout differences between browsers. There's not much information on functional differences from browser to browser. I wanted to ask, what are the typical functional problems that can arise in web applications.
Two sources of these problems came to mind right away are Javascript and server-side controls. What else should one watch out for?
There could be differences in the way the HTML is processed, in available Javascript functions, in CSS parsing. For Javascript differences there is a great library called Modernizr that allows you to easily check if the current browser supports a function.
In general server side controls are just returning html/javascript/css so there's no reason that depending on the client browser they will behave differently, unless there is code specifically to try to account for the browser's differences.
Another great resource for finding out what browser supports what is this can I use
How can I understand what engine is being used while JavaScript is executing?
e.g., v8 or spidermonkey or nashhorn
JavaScript engines (and their versions) are closely linked to browser (versions).
So simply use browser detection, and map it to the JS engine with a table. Many browsers even hold the engine build in their UA string.
Or better: Don't do it, for the very same reason. There's hardly a use case where you need to know the JS engine, apart from browser test suites (in which you just can ask the user). For anything else, you should use feature detection. Different engines differ in different ways from the ES spec, and you can test on these subtleties.
There's been a lot of talk about Google being forced to go with UIWebView for Chrome for iOS, and Facebook ditching HTML5 entirely for their iOS apps because UIWebView was too slow. I'll soon be needing to port an HTML5 application that requires lots of intensive Javascript computations (too much code to rewrite natively given my time constraints) but none of the display functionality that a browser provides (i.e. it works fine headlessly on Node.js). I've never heard of anyone trying to embed Google's V8 into an iOS app, but given that MobiRuby does practically the same thing (linking in the mruby interpreter), would it be permissible to do something similar, linking in Google's V8 interpreter within the same process? As long as code isn't downloaded, and processes aren't forked, it doesn't seem to be against the rules, but has anyone ever tried this?
EDIT: I'm aware of PhoneGap/Cordova and similar technologies, but they all work with a full UIWebView, and due to Apple's paranoia, UIWebView cannot JIT-compile Javascript code (which, as I said, is essential for my application).
According to what is mentioned in this this thread on the v8-dev mailing list, it may now be possible. You may be interested in the state of the work on this issue.
Is there any way to recognise pen pressure using javascript.
Preferably I don't want to make any use of Flash and try get this done as pure JS.
EDIT: okay I realised that it is kind of possible for Wacom tablets as they come with software that can work with their javascript api to make it possible (demos). But it's no good for people with Trust tablets or any other brand... So no good really.
Any body know how to do it in C# if not JS?
Yes - if the user has a Wacom tablet installed, then their browser will have a plugin for it that you can access. http://www.wacomeng.com/web/index.html
edit from author: I wrote this a very long time ago. Please see the comments below
Microsoft implemented something called Pointer Events in IE 11. It allows you to access pressure property along with stuff like pen tilt and size of contact geometry.
So far it only works on IE11 (and IE10 with vendor prefixes) but there is a W3C candidate recommendation so maybe it will be standard in future.
Javascript as a programming language in itself has no more ability or lack of ability to read this kind of data than any other language.
The language isn't important. What is important are the APIs available to you from within the language.
Javascript can be run in a number of different environments, some of which may possibly have access to APIs for this kind of hardware. However most Javascript is run in a web browser environment, and this is clearly what you mean.
The web browser environment provides a number of APIs. The most obvious is the DOM, which gives you the ability to manipulate the page, etc. There are other APIs available in the browser as well though. For example, the Geolocation API.
All these are standard APIs which have been defined by the W3C (or in some cases are in the process of being defined by the W3C), meaning that all browsers that support them should make them work the same way.
Unfortunately for you there isn't a standard API for working with pressure pads, so the direct answer to your question is no, it can't be done.
Whether one will become available in the future remains to be seen, but I have my doubts.
There is one way that you can do it though: ActiveX.
ActiveX is an API provided by Microsoft in older versions of IE. It basically provides a way of accessing virtually any Windows DLL code from within the browser.
Since the pressure pen device driver for Windows will be provided as a DLL, this means you should theoretically be able to access it in the browser via an ActiveX control. So therefore yes, you would be able to program it using Javascript.
The bad news, though, is that this is not something I'd recommend. ActiveX as a browser-based technology has long since been abandoned, due to the massive security holes it caused. I don't think the latest versions of IE even support it (I hope not, anyway), which means you'd be forced to use old versions of IE (and only IE - no other browser ever supported it) in order to run your code. Not ideal.
No, that's not possible. Probably not even with Flash.
You can only do so in an Native app. Javascript does not have access to pen pressure information
Is it necessary to test the rendering of my website in both Chrome and Safari despite the fact that both browsers implement the Webkit rendering engine underneath?
Is this a cop out by developers or a valid assumption to make?
I am specifically asking about whether the pages of my website will render the same in both browsers and whether my Javascript will work in both browsers.
There are some slight differences, so I would test in both. Some examples:
By default Safari has 3rd-party cookies disabled, but Chrome has them enabled by default.
Safari does not store <noscript> content in the DOM, Chrome does
Chrome keeps each browser window sandboxed in its own operating system process (multi-process model). Safari keeps all windows in one process. [Note though: The upcoming WebKit2 will have support for the multi-process model built in].
Chrome uses the V8 javascript engine, Safari uses Nitro.
I know there a few other differences I have encountered, but I can't remember them off the top of my head. I'll update this post if any occur to me.
They use different JavaScript engine, Chrome:V8, Safari:Nitro
Each browser may choose to include different features of webkit in their final versions, so they are not always the same.
Even different versions of Chrome will behave differently, same for different versions of Safari. So I wouldn't use this assumption, and would test in both browsers.
Interesting question, I was thinking about this earlier. I would say yes, just because the rendering engine is only one part of the browser. You also have to take into account that there are many versions of each browser still in use.
It doesn't take too long to test the page in ether, better safe then sorry.