FrontMotion FirefoxCE

The good guys at FrontMotion publish the Community Edition (CE) of Firefox as an .msi installer package which also supports group policy settings. Great work. They also keep their builds updated.

But one size doesn't fit all so I had to use orca (an MS utility) to make some changes to their .msi package and saved a transformation. My problem was their installer completely ignored any transformation I passed it in the msiexec command line. Looking over at the log, I watched the TRANSFORMS property being erased shortly after installation start. Strange. 

Following the KISS principal though, I just produced a new .msi file with my .mst file already applied and installed that instead. Voila!

jQuery, jRails and autocomplete

Recently, I choose to switch the Rails-bundled Prototype library with jQuery/jRails for a project. All went smooth (great job guys!) save for a catch: the autocomplete plugin stopped working :(

Looking for an alternative I stumbled on jrails_auto_complete plugin. It is supposed to be a drop-in replacement for the DHH Prototype one. And it indeed was.

With the DHH plugin, I had been using multi-line formating and styling in my list elements using DIVs insile the LIs. With the new jRails thing these multil-ine elements exhibited a small problem with mouse navigation and clicking in the drop down list elements:

• Mousing over list elements, would only highlight them when the pointer was hovering on the element border. Move a bit inside and the highlight was gone.
• Clicking to select would cause all the list element titles to be pasted in the text field causing a mess and of course, no actual selection was made.

Funny though, there was no problem navigating with the keyboard.

Googling I only found one relevant post by a guy experiencing the same thing and thanks to him I got some insight on what was actually going on. The plugin is relying on the mouseover event firing from the element to make the highlight and update the internal selection index. However, in my (our) case, child objects inside the LI element fired their own mouseovers as well, which bubbled up and where intercepted too. As child objects don't get a selection index property added, the plugin code just invalidated the selection, hence no highlight anywhere.

My (naive) solution was to change jrails_autocomplete.js as follows:

    onHover: function(e) {
       var my_index = e.target.autocompleteIndex;
       if (!my_index) {
         my_index = $(e.target).closest('li').attr('autocompleteIndex');
       }
       if (this.index != my_index) {
           this.index = my_index;
           this.render();
       }
       stopEvent(e);
   },

This basically searches the closest LI parent for an autocompleteIndex property if one isn't found in the element that fired the event.

For the second problem I just glanced over the keyboard part of the code which looked similar and finally decided to just comment out the line (re)setting the index out of the element clicked:

    onClick: function(e) {
        /*this.index = e.target.autocompleteIndex;*/
        this.selectEntry();
        this.hide();
    },

Thanks to the guy over at StackOverflow who gave me the heads-up with his question. It has been some time since he posted but I hope he finds my solution of some use.

HTML5 to the rescue!

The other day I needed to find a way for a web page to request data from another site.  I had control of the "other" site, but not on the web page itself. I could however place javascript on it, accessible through a link.

So, what had to be done was write some javascript that when activated on the proper page, should fetch data from the "other" site and update some things on the web page as it is viewed in the browser. A classic example of cross-site scripting...

Try 1:  xmlhttp API

NOT! The browsers go into great lengths to prohibit xmlhttp requests directed to pages not in the same server, or at least DNS domain. So this one is a no-no.

Try 2: window.open

Well, this solution would let me open the page on the "other" site where the data would be, but again, browsers go into great length to prohibit any interaction of pages like above. Most of the created window properties would become inaccessible as soon as the page started to load.

Bottom line: there is no way for javascript on one page to peek the contents of another, nor there will ever be one, as it is a huge security hole.

Try 3: greasemonkey

At least, something that would work. But, letting aside the minor(?) security issues and browser compatibility, the web page not under my control strictly forbids any greasemonkey scripts stored. The will shoot them on sight and ban the user. So... no go again.

Try 4: PostMessage/ message event

After enough looking around on how to circumvent xmlhttprequest restictions or greasemonkey alternative, Google stumbled onto a reference for this HTML5 feature. Which was exactly what I was looking for! And it is implemented exactly to allow intercommunication of 2 browser windows belonging to different sites.

Really! Google for PostMessage specifically, there are enough examples already on the net describing the API perfectly.

Virtualization nightmares

I decided it was time I dove into virtualization.

Day 1:

Set up a Windows XP guest with VirtualBox (3.1.2) on my atom netbook under Linux was very easy but of course slow. So I went on to make a cheap virtualization testbed. Used some components I had lying around: Asus P5L-MX, Intel Celeron Dual Core E3200, 1GB memory

The Asus wouldn't recognize the processor and there was no recent BIOS update for it, but would utilize it, overclock it easily (just kicked FSB to 266MHz) and run Linux like a charm. Also noted it would enable Vanderpool.

Imported the VM from my netbook to testbed computer, fired up VirtualBox (3.0.12) and... blue screen right after the loading screen and an oops logged in the host. Played with various settings, now the VM wouldn't start at all, instead the host would oops and I'd be left with a stale VM. 

Strange...

Day 2:

So then I said "OK, fine, I am going the KVM way".

Goodness, kvm (2.6.30.5)/qemu-0.12.1.2 worked and I proceeded to install a fresh WinXP guest, using a real partition this time instead of the disk image file. Installation went smooth, machine restarted and... right, blue screen. Tryed to boot a linux image (gparted-live-0.4.6-1.iso) in the VM as well but the kernel wouldn't go further than the uncompressing stage.

Played with qemu parameters a bit:

• Disabled kvm usage: VM came up fine. Enabled it again => Freeze. 
• -smp=1, worked with kvm!!! I was happy... a few tries later, it wouldn't... bugger.
• -cpu seemed to have no difference.

So I upgraded my kernel to the latest available at the time, 2.6.32.2 and tried again. Lo and behold, this time the host system would freeze (no oops) as soon as I started the VM. Holy ...

What was even more frustrating was that Google search results wound never mention a freeze with kvm/virtual box in the host (or if they did, it would date 2 years ago...). And frankly, a host freeze because of the bad guest would have been a showstopper, wouldn't it?

Day 3:

Ripped another machine from someplace: Asus P5B-VM, Core2Duo E6300. Then I hooked the hard disks from the testbed, booted,

• fired up kvm/qemu VM:  SUCCESS!!!
• tryed VirtualBox VM: SUCCESS!!! again...

So it is the testbed hardware, rather than the software...

Flash1: testbed doesn't really enable VM-X, because the BIOS doesn't recognise the CPU correctly.
Dim1: checked the msr 0x3a, it has the correct value... and kvm module doesn't complain about VM-X being disabled in BIOS either...

Flash2: microcode?

Had:
microcode: CPU0 sig=0x1067a, pf=0x1, revision=0x0
microcode: CPU1 sig=0x1067a, pf=0x1, revision=0x0

Updated with microcode-data v. 20090927. Got:
microcode: CPU0 updated to revision 0xa07, date = 2008-04-09
microcode: CPU1 updated to revision 0xa07, date = 2008-04-09

Result:
SUCCESSS!!!!

All VMs work!!! No BSOD, no freezes, linux guest (gparted image) now boots fine as well.

3 days spent over a non-issue, that is usually taken care by the BIOS during POST. Well, now I'll know better!