Firefox Javascript Engine

[Darth Gupta]

Ive noticed that Chrome and Firefox take different amounts of time to render certain things. In general, Chrome has been faster. What should I know about both of them (and IE8/9, too, I guess) when constructing a Javascript/jQuery app?

Actually, Spidermonkey (FF) and V8 (Chrome) are very similar in the core javascript engine API in that both try to be standards compliant. The main difference is that Spidermonkey tends to add some nice extras to their API if they feel it is needed. All of this is found at the Mozilla Development Center (MDC) for JavaScript and well documented if it is not a standard. On a side note, I personally search the MDC as my primary source for the JavaScript API.

This story is entirely different for IE. While most of the core API such as Math and String are the same, IE differs greatly when it comes to the document object, and any manipulation therein I would agree with balexandre and say that jQuery does a very good job at taking care of that mess for you.

The last thing that I will mention is while each engine will process the JavaScript code differently (some faster, some slower, etc.), but this can mostly be considered a black box and all you should need to worry about are the differences in the APIs.

If you write a jQuery app, you don't need to worry about anything as you are developing to a framework/library that does (today) and will continue to do (in future versions) everything under the hood.

The main advantage of this idea is the simple fact that Firefox compiles 6x faster than either WebKit or Blink. It is also fundamentally simpler than WebKit. Much, much easier to follow from a source code standpoint.

There are practical problems however. Most of the security architecture would have to be stripped (as it wouldn't be needed and would get in the way) and probably a lot of old functions like nsiFile access would have to be restored from scripting standpoint (return of enablePrivilege, or supplant with Node or something).

Yep I'd love to replace the android webview with Firefox, especially if it supported extensions like dark reader and ublock. So many apps force you to use the baked in webview (facebook messenger is a pain) instead of giving the user any choice.

This is essentially is request to embed nodejs runtime (read running v8 engine!) into the Firefox, and expose the same API as for firefox extension? If question is to attach window management & UI from firefox UI to Nodejs/v8 and expose the firefox-specific objects into global context like native v8 addons do, this is one thing.

What has me beaten is getting Javascript to work. There are 2 or 3 sources that Shepherd retrieves data from that require JavaScript . I recalled I had previously

followed the instructions on the Shepherd wiki for SuSE 10.x and it appeared to have worked ok,

I would like to resolve this Javascript issue. If I use Yast for installation there are several choices of Java, however it appears that the javascript most commonly used for shepherd is one from Mozilla (spidermonkey?). I tried installing the files for that from Yast and then to get the cpan JavaScript module working but failed.

The Java plugin is for executing Java applets. It is optional. Very few sites need the Java plugin, Flash seems to have won as the plugin language of choice. The Java plugin is not needed to execute Javascript. Javascript is built-in the browser.

Also, to be specific, you can run JavaScript outside your browser such as

with the Rhino project which lets you run a JavaScript engine under Java.

JavaScript is typically only used in browsers but it is not limited to

that one venue.

Some of the Perl modules which you may require as dependencies are available as openSUSE packages. For example if you need the XML::XPath module, the package to look for is perl-XML-XPath. This will show you all the Perl modules available:

Following the various suggestions I did a new search on OpenSuse Build repositories and was able to find perl-javascript-spidermonkey, thanks to the contributors to the build service. Once installed the problem was resolved.

All of HtmlUnit's JavaScript objects subclass SimpleScripable either directly or indirectly. This class contains all the common methods needed by the HtmlUnit host objects. Additionally, it changes the way that JavaScript method lookup happens. The rhino engine doesn't walk up the class hierarchy when looking for methods starting with jsGet_, jsSet_ or jsFunction. SimpleScriptable changes this so that the superclass hierarchy is walked.

Testing pages with JavaScript on them can produce a number of errors. These errors occur for several reasons. Some browsers accept shortcuts that are not part of the DOM model and currently not duplicated by HtmlUnit. Also, HtmlUnit still does not implement all extensions that have been added by the different browsers. HtmlUnit wraps the inline code into a wrapper function but when errors are reported from this code, it is hard to determine what code was really being called. A custom logger has been added to HtmlUnit to support this. If you set 'org.htmlunit.javascript' to debug level, the inline code will be logged with the wrapper function to help you determine what line of code is failing.

One of the problems with JavaScript is finding the objects that you expect to be defined but have not been defined within the code. To help find some of these errors, HtmlUnit will produce WARN level messages reporting these errors. Before submitting JavaScript bugs, please read this.

3a8082e126