Ivor O’Connor

November 14, 2009

Firefox to Chrome Switch

Filed under: CHROME, Firefox — Tags: — ioconnor @ 5:25 pm

I spent time on firefox irc channels this week, reachable via http://irc.mozilla.org/, only to become disgusted. They were completely clueless about using html5 to access sqlite databases. Not only clueless but hostile to the idea of ever using a browser as an application’s front-end. Then there was the lack of documentation on their development sites. Lots of stubs to be completed at future dates does not count as documentation. Because their servers are so incredibly slow it takes time to navigate through their pages to discover the details are merely placeholders. Plus the fact their irc channels were not reachable via common irc networks gave me an overall feeling Firefox has slipped. Badly. So since Firefox has lost its way I installed Chrome. Chrome comes with support for accessing local sqlite files which Firefox developers don’t even want to.

´╗┐http://www.ubuntugeek.com/how-to-install-chromium-google-chrome-in-ubuntu-using-deb-package.html is where I started. The instructions were remarkably good. Chrome seems to run fine on Ubuntu and Vista. I’m writing this post from Chrome. I’ll give myself a few weeks of getting familiar with Chrome…

Google Chrome adds additional JavaScript functionality through Gears. Gears is bundled with every Chrome install, adding new features to the web browser faster than previous plugins. The Gears libraries include support for new local cache structures, local databases, location data, background tasks, and file handling. Chrome boosts the available Gears footprint for web developers, including Google’s own apps such as Google Reader and Google Docs (and my blog). The current Gears code included in Chrome replicates V8 and sqlite code already present in the browser, a bolt-on that will hopefully be integrated in the near future.



So Gears is built in to Chrome like I had heard. Unlike Firefox the documentation looks good and exists here.

This all seems very Microsoft like. Taking over a market by buying out the best programmers and throwing lots of money around. Unfortunately the free alternative, Firefox, is in need of direction. Maybe Firefox will rise from the dead again but I suspect they will take years to regroup.



  1. Chrome has imported all my passwords successfully. It’s truly amazing how well it has done this.
  2. Chrome is magnitudes faster than Firefox. I had thought some sites were just slow but apparently it’s the javascript or rendering engine in Firefox that makes them so slow. With Google’s Chrome these sites are almost rendered in real time.


  1. Printing sucks. You’ll need to pull up whatever you want to print with Firefox and print from within Firefox. Problems with printing are:
    1. The keystorkes “ALT-f p” do not bring up the print panel. Instead the right mouse key is used taking your hands away from the keyboard. A minor problem but irritating.
    2. The print looks totally different, ugly, and incorrect with various lines that are not in the displayed version blotting out the output. If you don’t mind the stuff that’s printed which should not be printed it’s ok.
    3. The print out does not stop at the pages specified in the form. So specifying pages 1-2 will get you everything and then some since the print outs are bad. So trying to get just the current page of what I normally print out got me three pages. (Though there were only two pages to print!)

May 4, 2009

JavaScript Code Coverage On Ubuntu

Filed under: Code Coverage, Firefox, howto, Linux, tutorial, ubuntu — Tags: , — ioconnor @ 10:24 am

I’ve been playing with JavaScript looking for QA tools, getting JavaScript Lint in vim on Ubuntu, etc.. Now I’ve got code coverage analysis going for it. Follow these instructions to install JavaScript Code Coverage on Ubuntu:

  1. Download from and unpack.
  2. Change directory to where it was unpacked:

    cd jscoverage-0.4/
  3. Configure the environment for Ubuntu:

  4. Compile the program:

  5. Copy jscoverage-server to your personal bin:

    cp jscoverage-server /my/bin
  6. The jscoverage documentation does not mention it but you must start jscoverage-server from the directory where it is to be serving the javascript from. So to run their examples move to the directory where their example code is:

    cd jscoverage-0.4/doc/example/
  7. Now start up the coverage server from the same directory the javascript is located:

    jscoverage-server –verbose
  8. Open up a browser where index.html is the starting point of the code you are going to test:

  9. Execute the code a bit and then move to the store tab and press the store button.
  10. Open up another browser to view the results:

    firefox jscoverage-report/jscoverage.html
  11. Possibly open another browser, like opera, and test with it. All the additional tests will be added to the report.
  12. Now if you have the directory available via the network test the code with IE.

At this point it’s a simple matter of writing the javascript as a separate library.
Once in a separate library each function can be called separately.
Unit tests can then be written attempting to maximize code coverage and results can be verified.
Once this is done then the user interfaces can be tested.

There are some caveats listed in the manual. They all seem quite acceptable.

  1. JSCoverage adds instrumentation to JavaScript code, which will slow down execution speed. Expect instrumented code to take at least twice as much time to run.
  2. JSCoverage currently instruments only .js files; it does not instrument code in script elements in HTML files.
  3. HTML files must use relative URLs to reference scripts. If you use an absolute URL, your page will reference the original uninstrumented script rather than the instrumented one, and no code coverage data will be collected.
  4. JSCoverage instruments physical lines of code rather than logical JavaScript statements; it works bests with code that has exactly one statement per line. If you put multiple statements on a line, or split a line across two or more statements, you may get strange results.
  5. JSCoverage uses frames. Some web pages that use frames may not function properly when run under JSCoverage, especially those which try to access the top-level frame (window.top, target=”_top”, etc.).

I don’t see any way of incorporating the results into vim.
It would be nice if that were possible though.
I think the best that can be done would simply be to start a page that would call the various functions with assert statements.
Perhaps via a bash script.
Maybe I’ll learn more when I look into the jsunit tools.
As it now stands all of the error paths are questionable.
Still it’s better than no code coverage.

May 2, 2009

JavaScriptLint, Vim, And Ubuntu

Filed under: debugging, Firefox, Lint — Tags: , , , , , , — ioconnor @ 7:30 pm

In my blog https://ioconnor.wordpress.com/2009/04/24/javascript-testing/ I looked into some tools to help in my JavaScript development. I haven’t had the time, (or urge?), to do anything until this morning. This morning though I got JavaScriptLint working. The documentation at the site is less than adequate so I’m adding notes here to help me if I need to install it again in the future.

  1. The Linux download is here: http://www.javascriptlint.com/download.htm
  2. After decompressing it you’ll notice there is only a single horribly wrong README.html file. To get things working compile it by going to the src directory and typing:
    make -f Makefile.ref
  3. A jsl will now be found in jsl-0.3.0/src/Linux_All_DBG.OBJ/jsl. To make it generally accessible do something like:
    ln -s /whatever/jsl-0.3.0/src/Linux_All_DBG.OBJ /my/bin/jsl
  4. Running jsl will show the parameters that are needed. If you are like me you’ll wonder where the configuration file is that they mention. It’s not on their website and it certainly is nowhere on my disk. So I googled around until I found it, or close to what it should probaly be, and have copied it down below. I called the file “jsl.conf” and stuck it in /my/bin/jsl.conf.
  5. It’s all fine and good running it on the command line. It even looks at the javascript code in html files. I found quite a few questionable pieces of code and one clear mistake on my part that fortunately was not causing any problems. From the command line type something like:
    jsl -conf /my/bin/jsl.conf -process /my/dev/taxes2.html
    The -conf /my/bin/jsl.conf is optional.
  6. To run it from within vim by pressing the <F9> key edit the vimrc file and include something like:
    map <F9> : call JavaScriptLint()<CR>
    func! JavaScriptLint()
    exec “w” “Save the file
    exec “!jsl -conf /my/bin/jsl.conf -process % ”

I might change this so the editor dumps me on the line that’s bad with an error message. Or into an error file that can be toggled back and forth from. However it is usable enough for me in it’s current form.

The conf file I’m using looks like this:

# Configuration File for JavaScript Lint 0.3.0
# Developed by Matthias Miller (http://www.JavaScriptLint.com)
# This configuration file can be used to lint a collection of scripts, or to enable
# or disable warnings for scripts that are linted via the command line.

### Warnings
# Enable or disable warnings based on requirements.
# Use “+WarningName” to display or “-WarningName” to suppress.
+no_return_value # function {0} does not always return a value
+duplicate_formal # duplicate formal argument {0}
+equal_as_assign # test for equality (==) mistyped as assignment (=)?{0}
+var_hides_arg # variable {0} hides argument
+redeclared_var # redeclaration of {0} {1}
+anon_no_return_value # anonymous function does not always return a value
+missing_semicolon # missing semicolon
+meaningless_block # meaningless block; curly braces have no impact
+comma_separated_stmts # multiple statements separated by commas (use semicolons?)
+unreachable_code # unreachable code
+missing_break # missing break statement
+missing_break_for_last_case # missing break statement for last case in switch
+comparison_type_conv # comparisons against null, 0, true, false, or an empty string allowing implicit type conversion (use === or !==)
+inc_dec_within_stmt # increment (++) and decrement (–) operators used as part of greater statement
+useless_void # use of the void type may be unnecessary (void is always undefined)
+multiple_plus_minus # unknown order of operations for successive plus (e.g. x+++y) or minus (e.g. x—y) signs
+use_of_label # use of label
+block_without_braces # block statement without curly braces
+leading_decimal_point # leading decimal point may indicate a number or an object member
+trailing_decimal_point # trailing decimal point may indicate a number or an object member
+octal_number # leading zeros make an octal number
+nested_comment # nested comment
+misplaced_regex # regular expressions should be preceded by a left parenthesis, assignment, colon, or comma
+ambiguous_newline # unexpected end of line; it is ambiguous whether these lines are part of the same statement
+empty_statement # empty statement or extra semicolon
-missing_option_explicit # the “option explicit” control comment is missing
+partial_option_explicit # the “option explicit” control comment, if used, must be in the first script tag
+dup_option_explicit # duplicate “option explicit” control comment
+useless_assign # useless assignment
+ambiguous_nested_stmt # block statements containing block statements should use curly braces to resolve ambiguity
+ambiguous_else_stmt # the else statement could be matched with one of multiple if statements (use curly braces to indicate intent)
+missing_default_case # missing default case in switch statement
+duplicate_case_in_switch # duplicate case in switch statements
+default_not_at_end # the default case is not at the end of the switch statement
+legacy_cc_not_understood # couldn’t understand control comment using /*@keyword@*/ syntax
+jsl_cc_not_understood # couldn’t understand control comment using /*jsl:keyword*/ syntax
+useless_comparison # useless comparison; comparing identical expressions
+with_statement # with statement hides undeclared variables; use temporary variable instead
+trailing_comma_in_array # extra comma is not recommended in array initializers
+assign_to_function_call # assignment to a function call
+parseint_missing_radix # parseInt missing radix parameter

### Output format
# Customize the format of the error message.
# __FILE__ indicates current file path
# __FILENAME__ indicates current file name
# __LINE__ indicates current line
# __ERROR__ indicates error message
# Visual Studio syntax (default):
+output-format __FILE__(__LINE__): __ERROR__
# Alternative syntax:
#+output-format __FILE__:__LINE__: __ERROR__

### Context
# Show the in-line position of the error.
# Use “+context” to display or “-context” to suppress.

### Semicolons
# By default, assignments of an anonymous function to a variable or
# property (such as a function prototype) must be followed by a semicolon.

### Control Comments
# Both JavaScript Lint and the JScript interpreter confuse each other with the syntax for
# the /*@keyword@*/ control comments and JScript conditional comments. (The latter is
# enabled in JScript with @cc_on@). The /*jsl:keyword*/ syntax is preferred for this reason,
# although legacy control comments are enabled by default for backward compatibility.

### JScript Function Extensions
# JScript allows member functions to be defined like this:
# function MyObj() { /*constructor*/ }
# function MyObj.prototype.go() { /*member function*/ }
# It also allows events to be attached like this:
# function window::onload() { /*init page*/ }
# This is a Microsoft-only JavaScript extension. Enable this setting to allow them.

### Defining identifiers
# By default, “option explicit” is enabled on a per-file basis.
# To enable this for all files, use “+always_use_option_explicit”

# Define certain identifiers of which the lint is not aware.
# (Use this in conjunction with the “undeclared identifier” warning.)
# Common uses for webpages might be:
#+define window
#+define document

### Interactive
# Prompt for a keystroke before exiting.

### Files
# Specify which files to lint
# Use “+recurse” to enable recursion (disabled by default).
# To add a set of files, use “+process FileName”, “+process Folder\Path\*.js”,
# or “+process Folder\Path\*.htm”.
#+process jsl-test.js

April 24, 2009

JavaScript Testing

I’m finding my JavaScript code is not behaving as I’d like it to. Code I thought was solid and have been using consistently is less than solid. Code involving money. So it’s time to start rigorously testing things as if I were coding in C/C++. At http://www.opensourcetesting.org/unit_javascript.php is a list of free tools that can help.

  1. CrossCheck. It seems to concentrate on verifing the code will run on multiple browsers. Making sure things work on buggy browsers like IE is not big on my list.
  2. JavaScript Assertion Unit. Assertion testing. Might be all I need. Probably not though. I don’t want to complicate the code itself. I’d like to have a separate unit supplying the input and comparing it to expected results that can be used by code coverage tests too.
  3. JSCoverage. This runs the latest Linux and Firefox distros and looks very promising. It only checks coverage though. Nothing else.
  4. JSMock. The documentation is less than clear. I can’t tell if it can be automated, if it runs on Linux, or even what it does. Hopefully it allows test scripts to suppy and perhaps change values within the called functions and compare the results. However if it does do this it does not plainly say it.
  5. JSNUnit. A product made for M$ environments. Does not work in Linux.
  6. JSUnit. Tests multiple browser javascript on multiple OSs. It looks very promising in that you can write test scripts to run the pages, functions, and possibly even alter values. Hopefully allowing the JSCoverage to run at the same time. I’ll probably start with this tool.
  7. JSUnit. I’m not sure how this one differs from the other JSUnit. I’d best compare the two carefully before deciding which one to use.
  8. RhinoUnit. It is tied to ANT. It mentions having integrated support for JSLint.
  9. JSLint. I’m not sure if this can be run standalone. Perhaps this page will explain it better: http://www.jslint.com/rhino/index.html
  10. JavaScript Lint. Hmmm.

Some of the criteria I’m looking for are:

  1. Fully Automatable.
  2. Speed.
  3. Ease.
  4. Runs on Linux.
  5. Coverage Check.
  6. Free.
  7. Actively supported.
  8. RegEx comparisons.

The Lints are the natural place to start. I’ll somehow make some bash scripts to test them and go from there.

April 20, 2009

Firefox Beating IE?

Filed under: Firefox — Tags: — ioconnor @ 6:13 pm

There’s a site at http://gs.statcounter.com/#browser_version-na-daily-20080701-20090420 which shows just how well each of the browsers are doing as a percentage of a particular market and globaly. It’s not clear how accurate this is. For instance there’s no indication of how many people are using it. Perhaps it’s a hobbist tool appealing to mostly poor Firefox users? Google analytic data would be much better since businesses use their tools. Unless the stats from multiple bean counters agree with each other their data is questionable.

The above site made the news because they claim Firefox is now more popular in Europe than any other broswer. Almost more popular than all the IE versions put together. It’s about time! However until other bean counters corroborate their story I’ll treat this information as an outliner. A stat outside the bounds of realism that should not be used for any serious planning. Other than as a conversation point…

April 4, 2009

Stripped Google Gears Causing Accidents

Filed under: debugging, Firefox, GEARS, GOOGLE, howto, JavaScript, Linux, tutorial, typeof, ubuntu — Tags: , , , , , — ioconnor @ 12:02 am

Attempting to use Google Gears when it is not installed on a user’s browser causes an error. You’d think their library would handle this more gracefully than just crashing but it doesn’t.
UPDATED 2009.04.04: Their library should define the call but return something akin to an alert warning the user/developer

The crash occurs on this line:

g_db = google.gears.factory.create(‘beta.database’);

I pulled out my “JavaScript The Definitive Guide 5th Edition” looking for how to get around this. (This is my primary reference book for all things JavaScript. Perhaps if I were better at JavaScript it would be second nature but I’m not good at JavaScript so I spend lots of time looking things up.) I figured “google…” was not defined. So I looked at the index and put a paperclip on each page in the book referenced by the index. Then I tried all sorts of combinations none of which would work. Things like:

if (google === undefined) {
} else {


if (google == undefined) {
} else {


if (“gears” in google) {
} else {


if (google) {
} else {


if (google.gears) {
} else {


if (“length” in google) {
} else {

but none of above worked! There were no other solutions in my reference book. My reference book doth sucketh.

So I used a try/catch for a while but I’d still get an error message in the “error console”. The try/catch is ugly but it let me do what I needed and polluting the error console seems to be acceptable. Everybody does it. Just leave the error console open while browsing the web to see how rampant the pollution is.

However I revisited this problem today. After extensive googling seeing all sorts of “solutions” that were similar to the above and which did not work I happened to find the following:

if (typeof(google) == ‘undefined’) {

I’m using Firefox 3.0.8 if this makes any difference. It’s the very latest version as of this month from Mozilla. I’ve got to remember this solution in the future!

Blog at WordPress.com.