It is well known that Firefox (even the latest 3.x) does not support text-decoration=”underline” on text elements in SVG. However, it bites me hard when I found out imagemagick does not support that either when rastering svg to pixel images.

After digging around, (by looking at the ebuild file) I found out that imagemagick is actually making use of librsvg to do the heavy lifting when dealing with svg files.

librsvg is part of gnome-base packages (as can be seen in gentoo portage). Looking at the source code, I figured that it makes use of pango to render text.

From the days of working on SCIM project, I know for sure that pango is more than capable of rendering text with underlines. So there must be something missing in librsvg to render it. It turns out that, while the svg parser implemented in librsvg does indeed look for text-decoration, and recoganize underline (among strikethrough and overline), it is not actually making use of these parsed info to render the text.

After a bit of tracing the code, I found out how to patch it: the trick is just to add a pango underline attribute to the text layout, and everything else is taken care of by pango.

This bug is reported to upstream, and hopefully it will be merged there soon. The patch is available in that bug report, so you can grab it if you can’t wait. The patch also fixes a bug which is discovered after the underline problem is fixed: when a underlined text has stroke set, the stroke is rendered in wrong position.

This is a quick and simple tip for deleting multiple DOM nodes in JavaScript using the Dojo Ajax Toolkit.

A common pattern in non-trivial Ajax applications is the need to delete many nodes that may or may not have been created.  The code to do this without Dojo (or a similar library such as jQuery) would look something like the following code (assuming nodes are identified by ID):

var nodeIDs = ["node1", "node2", "node3"];
for (var i = 0; i < nodeIDs.length; i++) {
 var node = document.getElementById(nodeIDs[i]);
 // Verify that the node actually exists, otherwise an error occurs
 if (node) {
  node.parentNode.removeChild(node);
 }
}

This is of course a bit messy.   It would be infinitely messier if you needed to match nodes not by ID, but by another method such as by class name, relative position to it’s parent or sibiling nodes etc.

To achieve the same in Dojo, use this simple code.

var nodeIDs = ["#node1", "#node2", "#node3"];
dojo.query(nodeIDs.join(”,”)).orphan();

Update: There is a bug in Dojo that means that if the node with ID “node2″ does not exist, “node3″ will not be deleted.  (Thanks to Pete Higgins for letting me know). Instead use the following code:
dojo.forEach(arr, “dojo.query(item).orphan();”);

Very simple, and much smaller and cleaner than the previous example.  It also scales very well to match nodes using CSS selectors, not just by ID.  For example, to delete nodes both by ID and class name, use the following code.

var nodeIDs = ["#node1", "#node2", ".className1", ".parentClass .childClass"];
dojo.query(nodeIDs.join(”,”)).orphan();

Update: as with the first example, replace the second line with:
dojo.forEach(arr, “dojo.query(item).orphan();”);

For more info on the cool features of dojo.query, see the docs at http://docs.dojocampus.org/dojo/query .

      

We're going to be holding a meeting in our IRC room on January 2nd, at 1PM EST. The topics we'll cover can be found on our development wiki.

The meeting will be held in our IRC room on freenode, #psychdesktop. If you don't have an IRC client installed, you can use the chat applet on the contact page.

Although this is a developer meeting, you are welcome to give feedback regarding Psych Desktop.

We'll see you there!

Cheers!
The IE Team

As part of Mozilla Corporation’s ongoing stability and security update process, Thunderbird 2.0.0.19 is now available for Windows, Mac, and Linux as a free download from www.getthunderbird.com.

Due to the security fixes, we strongly recommend that all Thunderbird users upgrade to this latest release.

If you already have Thunderbird 2.0.0.x, you will receive an automated update notification within 24 to 48 hours. This update can also be applied manually by selecting “Check for Updates…” from the Help menu.

For a list of changes and more information, please review the Thunderbird 2.0.0.19 Release Notes.

Please note: If you’re still using Thunderbird 1.5.0.x, this version is no longer supported and contains known security vulnerabilities. Please upgrade to Thunderbird 2 by downloading Thunderbird 2.0.0.19 from www.getthunderbird.com.

After a great turnout this year, we are continuing our monthly online Expert Zone chats with the IE Team in 2009. Here is our schedule for the first half of next year:

January 22nd

February 19th

March 19th

April 23rd

May 21st

June 18th

 

All our chats start at 10.00 PST/18.00 UTC.  These chats are a great opportunity to have your questions answered and hear from members of the IE product team.  In case you miss the chat, a transcript will be published afterward and available online. Previous chat transcripts can be found here.

See you in the new year!

Allison Burnett
Program Manager

In a desktop environmen, menus (be it context menu or menu in menubar) have a column which display the accelerator key (or shortcut key in windows). In the 0.4 dojo Menu widget, we used to have that support, but it was not ported to 1.x.

After seeing Bill’s commit to add a real MenuBar to dijit, I think it’s the time to bring back this feature. For now, see the test_Menu.html test file for a demo.

A new property is introduced for dijit.MenuItem, called accelKey, of type String. It can be set either in markup or in the arguments passed to the dijit.MenuItem constructor (the demo contains examples for both of them). In addition, dynamically setting it is also supported, such as:

//item is a dijit.MenuItem object
item.attr("accelKey","Ctrl+W");

As mentioned in the demo, this accelKey is only a string, you can basically pass in any string you want. However, when the combination is pressed, it won’t actually trigger the action associated with the menu item: that has to be done explicitly elsewhere (such as dojo.connect to body’s onkeydown event, and detect whether a recognized accelerator key is pressed, if so, invoke the corresponding event handler).

I checked in some changes over the past few days to support both horizontal menus (aka MenuBar) and vertical menus statically appearing on a page, rather than popping up. i.e., menus that are always visible.

Give it a whirl. For now, see the test_Menu.html test file for a demo. (Eventually we'll get the demos into the new doc.)

The horizontal menu is called MenuBar and is similar to the "File" menu on all windows/mac applications; should be familiar to everyone. Previously we recommended using Toolbar but this is more menu-esque since you don't have to click to open the sub-menus.

The vertical menu is actually an enhancement of the old Menu widget, letting it appear statically on the page, rather than as a popup. Just don't specify the contextMenuForWindow or bindDomNodes parameters when initializing a Menu. widget.

As usual, keyboard arrow key (plus ESC and TAB) navigation, as well as BIDI, are supported out of the box.

For the vertical menu, without CSS modification it appears just like a popup Menu.... but typically I think people will want it to extend the full length of the page, so I modified the CSS in the test file to do that (putting the background shading on the entire left column, and hiding the borders of the Menu.

Bill

Boxing Day Morris Dancers from JP Sykes on Vimeo.

A large part of me, will always want to be in Swithland on Boxing Day. To anyone who can get to a small country pub, sit by a fire, drink hand pulled beer and then watch Morris Dancers, I wish you one and all and Happy Boxing Day !

By default, dijit.form.DropDownButton requires a dropdown menu specified when initializating. However, with a little bit of patching via subclassing it, we can easily achieve lazy loading of the dropdown menu: only creating it the first time a user clicks on the button. This will speed up the initial loading time of the application, especially if a lot of these type of buttons are present on the page.

Here is the core of how to achieve lazy loading:

dojo.declare("MyDropDownButton", dijit.form.DropDownButton, {
	dropDown:1,
	_openDropDown: function(){
		if(this.dropDown===1){
			this.dropDown=new dijit.Menu();
			var items=[{label:'One'}, {label:'Two'}, {label:'Three'}];
			dojo.forEach(items,function(args){
				this.dropDown.addChild(new dijit.MenuItem(args));    
			},this);
		}
		this.inherited(arguments);
	}
});

The trick here is to set dropDown to something which evaluates to true so that when clicked the first time, DropDownButton will proceed to call _openDropDown, where we have a chance to create the real dijit.Menu we want to show. Without line 2 above, _openDropDown won’t be called because DropDownButton thinks there is no attached dropdown menu.

As you may have already figured, in order to use this, the Menu has to be created programmatically.

On pages 19-20 of my book, you’ll notice a handy table of the various configuration switches you can pass to djConfig to customize aspects of the bootstrapping process.  A sidebar I’d like to have included (and will include in a future printing or update) involves some additional explanation about how the debugAtAllCosts option works, and incidentally, explains some important nuances between the “normal” loader and the XDomain loader in the process.

At a glance, debugAtAllCosts is simply what you use to try and get some more specific debugging information when something has gone wrong and Firebug or Firebug Lite aren’t giving you much to work with. Oftentimes, a quick update to djConfig with debugAtAllCosts:true is all it takes to get that helpful information and isolate the issue.

But how does it do that?

Detour: A Primer on the Loaders
To better understand how debugAtAllCosts works, it’s critical to first understand the difference between the “normal” loader and the XDomain loader. (Recall that the XDomain loader works around the same origin policy and is used to bootstrap the toolkit from a domain that’s different from where your web page is located to bring your page to life with Dojo goodness e.g. AOL’s CDN and such things.) To illustrate, consider a simple HTML page that might have a script block in it that looks something like this:

dojo.require(”A”);
dojo.require(”B”);
dojo.require(”C”);

In the general case when the “normal” loader is being used, each of those three dependencies is evaluated synchronously such that the scripts for A, B, and C are each fetched in turn, and any dependencies are processed in a depth-first search fashion. For example, if B had dojo.require’d modules named D and E (in that order), then the overall order of requests look like A -> B -> D -> B -> E -> B -> C. Note that B is listed multiple times in that chain because B begins loading, then at some point (maybe immediately) D is processed, then E is processed, and then control returns to B one last time before C gets kicked off.

It’s worth reiterating is that the execution of D and E are “blocking” in the sense that B begins executing, then when the dojo.require(”D”) statement is reached within B, D is processed on the spot before B finishes executing; ditto for the way that E works.

With the “normal” loader, the entire process is entirely predictable every single time. You can not only count on the dojo.require dependencies being resolved properly, but you also have an implicit guarantee about the relative order of various dojo.require statements that appear sequentially in the same source file as in the previous example.

The XDomain (cross-domain) loader, however, does something different by necessity of the way it circumvents the same origin policy, which can’t be done with dojo.xhrGet. It uses information provided through other djConfig switches such as baseUrl and modulePaths, or uses information provided via the dojo.registerModulePath function to build URLs that serve as the SRC attribute for dynamically insert SCRIPT tags that get inserted into the HEAD of the page. Moving forward, realize that the dynamic insertion of SCRIPT tags is an operation that is asynchronous in nature.

One of the most significant differences to note is that while dojo.require dependencies are still preserved by the XDomain loader, the relative order in which non-dependent modules become ready (where “ready” roughly corresponds to “alive” or “fully processed”) is not necessarily preserved. In our working example, this means that while the XDomain loader guarantees that D and E will be ready before B is ready, it guarantees nothing about whether D will be ready before E or if E will be ready before D — nor does it guarantee anything about the relative order of A, B, or C becoming ready. The reason why there are no such guarantees is simply due to the nature of asynchronous requests and latency.

To make sure you fully grasped the important nuances in that paragraph, here are a few of the possible scenarios with the XDomain loader for our toy example:

D -> E -> B -> A -> C
A -> C -> D -> E -> B
A -> C -> E -> D -> B
E -> A -> D -> C -> B

Note that in all scenarios, both D and E are ready, in no particular order, before B is ready. That’s the only commonality.

If you stop to ponder for a moment, you’ll recognize that a really easy way you could not only get into trouble but also cripple yourself from trivially porting your application to take advantage of the XDomain loader would be if you constructed logic that depended on the relative order of modules loading. For example, if you were counting on module A in the working example to perform a synchronous dojo.xhrGet request to retrieve some kind of global object that gets used throughout your application and module B, C, D, or E relied on it, you’d have a race condition on your hands if you tried to go with an XDomain build because there’s no guarantee that A will finish loading before any of the other modules; maybe it will, but maybe it won’t. For XDomain loading scenarios, if you truly wanted to guarantee that A would load before every other module, you’d have to go as far as to identify A as a dependency such that everything else that needs to block on it would block on it.

Getting Back to How debugAtAllCosts Works
Getting back to debugAtAllCosts and how it does what it does — basically, it forces the XDomain loader into effect, which causes each module to be individually loaded via a dynamically inserted SCRIPT tag as opposed to building up the equivalent of what’s analogous to a deeply nested parse tree that causes the underlying JavaScript engine to “just crap out” and give you a nearly useless error message when the going gets tough. Thus, while it can often work wonders and help you find some kinds of errors in a hurry because of the way it loads individual modules in isolation, it can also complicate your situation (for reasons that should now be obvious) if you haven’t been precise in identifying dojo.require dependencies or  are relying on the relative order or modules loading.

And as Paul Harvey would say, “now you know…the rest of the story.”

What an exciting year this was DojoCampus.org was launched early 2008, Dojo published several amazing releases with an unbelievable amount of enhancements, new features, fixes and much more. We had several Dojo beers, the DDD in Boston, podcasts, new book releases, ZendFramework integration - I wonder what will come in 2009 At this point [...]

I put together a short video showing some things Lucid/Psych Desktop can do.

The video was shot in full 720p, so go take a look.

It's also on youtube, but for some reason it's not showing up in HD.

We're going to post more videos in the future, so feel free to subscribe to the channel.

For anyone using Dojo v1.2.3 and the Nihilo theme, you may have noticed that performing a build with it breaks your styles.  After much tracking down, it turns out that there is abug in Nihilo’s Button.css.

On line 80, there is an extra curly brace

.nihilo .dijitComboBoxActive .dijitDownArrowButton {

which should be

.nihilo .dijitComboBoxActive .dijitDownArrowButton,

I’ve submitted a bug at http://bugs.dojotoolkit.org/ticket/8311, which should be in v1.3.  However, if you need a fix before that (as Nihilo is pretty unusable without it) just change that one line and you’re back in business.

      

i wish I’d had time to put together some sort of monome remix. I spent a couple of hours the other night trying something out on the arduinome, but I couldn’t find a decent way to save the audio and didn’t really have time to finish it off.

So in lieu of something I made, here is smashtron3000’s awesome B.I.G remix of Jingle all the Way.

Merry Christmas everyone and Happy New Year !

In this issue…

• Mobile Firefox (Fennec) alpha 2 released
• Firefox 3.0.5 and 2.0.0.20 now available
• “Fox For All” wins Impact Mozilla
• Camino 1.6.6 released
• Fireunit, testing in the Firebug world
• Firebug in Firefox 3.1b2 and beyond
• JSON explorer for Firebug
• New Mozilla design community mailing list
• Localization Testing and QA survey
• Interview: Mozilla Weave project lead
• Quality Assurance community site now in beta
• Automatic project creation coming to Mozdev
• New Firefox feature videos on mozilla.com
• Last issue of 2008!
• Developer calendar
• Subscribe to the email newsletter

Mobile Firefox (Fennec) alpha 2 released

Stuart Parmenter writes, “We’re happy to announce that our second alpha release of Fennec has come together. While we focused much of the previous alpha on getting the user experience how we wanted, we’ve spent much of the time since focused on improving performance. We’ve made major strides improving startup performance, panning and zooming performance, and responsiveness while pages are loading. We’ve refactored a significant amount of the front end code resulting in substantial speed improvements as well as providing a much better base for extension authors to build upon.”

Additionally, the Fennec team has released desktop versions of mobile browser as they did with Fennec alpha 1, which you can download for Windows, OS X, and Linux. These builds allow content and extension authors to experiment with the mobile browser on their desktop. Release notes are available for Fennec alpha 2, with information on how to install the browser, what’s new, known issues, and how to provide feedback. Further information can be found in Stuart’s original announcement.

Firefox 3.0.5 and 2.0.0.20 now available

As part of Mozilla Corporation’s ongoing stability and security update process, Firefox 3.0.5 and Firefox 2.0.0.20 are now available for Windows, Mac, and Linux. Mozilla is not planning any further security and stability updates for Firefox 2, and we recommend that you upgrade to Firefox 3 as soon as possible. Additionally, the Phishing Protection service will no longer be available for Firefox 2 users. Firefox 3 offers a new and improved Phishing and Malware Protection service, so again, we strongly urge you to upgrade to Firefox 3. You can download Firefox 3 at GetFirefox.com

“Fox For All” wins Impact Mozilla

Mozilla is proud to announce “Fox For All” as the grand prize winner of Impact Mozilla. “Fox For All” was authored by Phani Kumar Vadrevu and Uttam Byragoni of India. “We’re extremely grateful to all ten finalists. The degree of hard work and the diversity of ideas contributed by the teams far exceeded all expectations. Impact Mozilla also succeeded in reaching out to groups not traditionally part of the Mozilla community (e.g., MBA students).” More information about the wrapping up of Impact Mozilla can be found at the Mozilla Blog.

Camino 1.6.6 released

The Camino Browser team has just released Camino 1.6.6, a maintenance release which contains various security and stability updates. All Camino users are urged to update. In addition, Camino 1.6.6 is now available in the following languages: Catalan, Czech, Dutch, English (US), French, German, Italian, Japanese, Norwegian (Bokmal), Polish, Portuguese (Brazillian), Russian, Spanish (Castellano), and Swedish. You can download Camino at CaminoBrowser.org.

Fireunit, testing in the Firebug world

Jan Odvarko and John Resig have been working hard on a new Firebug extension called Fireunit. Fireunit provides a simple JavaScript API for doing test logging and viewing within a new tab of Firebug. Jan writes, “This very promising extension is intended as an automated testing framework for Firefox extensions and it should also be useful for testing web pages in the future. It’s still at the beginning, but growing and starting to be very useful for testing Firebug itself.” For more information, you can read Jan’s blog post and John’s blog post, and the extension itself is available at Fireunit.org.

Firebug in Firefox 3.1b2 and beyond

Rob Campbell has written a blog post where he clarifies some of the confusion that has been recently surrounding Firebug and its compatibility with Firefox 3.1. Not only is Firebug 1.2.1 not compatible with Firefox 3.1, neither is Firebug 1.3. “If you want to use Firebug with Firefox 3.1, you will need to use Firebug 1.4. Get the latest version from the releases directory and install it. No compatibility override required. Don’t let the alpha version tag frighten you, it’s really quite decent.” Details about the different versions are available on GetFirebug.com’s releases page.

JSON explorer for Firebug

In another bit of Firebug-related news, Jan Odvarko writes, “Thanks to Ashish Datta, Firebug has fresh new support for inspecting JSON in net responses. This feature allows you to see JSON formatted as an expandable tree of items and also explore them using Firebug’s Dom tab. The view is available within the Net panel and is visible as soon as a JSON request is expanded. This feature should be part of Firebug 1.4a11. Ashish is a senior at Tufts University and he did this work as part of his class focusing on open source development. It’s great to see how community around Firebug is growing and willing to contribute to this indispensible tool!” For more information see Jan’s blog post, and find out more about Firebug at GetFirebug.com.

New Mozilla design community mailing list

John Slater, part of Mozilla’s super fun marketing team, writes, “Following the successful examples of our developers, localizers, marketers, QA testers, etc we’re going to be making a major push to organize and grow our visual design community. I’ll share more details soon — including our plans to create a new site for posting and sharing your artwork — but if you’re curious to learn more the first thing to do is sign up for our new design mailing list.”

“Of course, there already is a Mozilla design community — just look at the 3,500+ people who participated in our Firefox 3 t-shirt design contest or Google around for Firefox art — but there’s so much more that can be done. This is an entirely new way we can put our greatest advantage to good use, and we should get a lot of cool stuff to look at, too. The possibilities are incredibly exciting.” For more information, see John’s post and sign up for the mailing list.

Localization Testing and QA survey

The l10n-drivers team recently launched a Testing and QA survey targeted at the localization community. The survey will remain open until December 26th. Stas Malolepszy writes, “Many localization teams have worked out their own practices and procedures regarding testing. So it’s natural that when Mozilla starts thinking about localization testing plans, we first look at what’s been already invented and proved to work well. There are many localization teams, each with their own way to test the localization, suited for their needs and resulting from their approach and past experience. What if we could share these practices between the localization teams and help other teams adopt them? This briefly summarizes the objectives of the survey.” If you are part of the Mozilla localization community and would like to help, you are strongly encouraged to take the survey. For more information, see Stas’ blog post.

Interview: Mozilla Weave project lead

Dan Mills, Lead Engineer of Mozilla Labs’ Weave project sat down with Aza Raskin for a brief chat. In this video he talks about what Weave is, what it’s good for, how it ties in with Firefox Mobile, when it will be in users’ hands, and what you can do to help. View the full video interview.

Quality Assurance community site now in beta

Jay Patel writes, “After over a year and a half of experimentation, discussion, design, development, and testing…I am proud to announce the launch of the ‘official’ QMO beta. While we used to rely on our team mailing list and the QA blog on mozillaZine, we now have a robust community website that I believe will help bring the Mozilla QA team and our growing community of volutneers together. We will be able to better collaborate to improve the quality of all Mozilla products and services, and QMO will provide a place for others to join us and learn more about Mozilla QA.” For more info, see Jay’s blog post, or head right on over to the new QMO website.

Automatic project creation coming to Mozdev

silfreed writes, “It’s been a long time coming, but your requests to speed up the project creation process are coming to fruition. Over the past couple of years there have been two major pain points in setting up new projects: tracking the requests to make sure they’re handled properly and actually creating projects. We finally have the tools in place to handle tracking the project requests and creating projects which should dramatically increase the response time of setting up new projects. We still have some work to do, but we’re well on our way to making those things happen.” Further details are available at silfreed’s weblog, and you can request a project at the Mozdev site itself.

New Firefox feature videos on mozilla.com

The Mozilla Blog reports, “We’ve launched a new video section on mozilla.com to help bring some of the many great features of Firefox alive. The feature-specific videos are narrated by the people who helped bring them to Firefox. The new video section even includes a walk through on how to install Firefox — perfect to help people make the switch.” The videos currently include: Firefox 3 overview, How to switch to Firefox with Asa Dotzler, Security features in Firefox 3 with Johnathan Nightingale, Bookmarks and tags with Alex Faaborg, and the Awesomebar with Seth Spitzer.

Last issue of 2008!

Just a quick reminder that this is the last issue of about:mozilla for 2008. We will resume our regular weekly schedule after the holidays, either January 6th or January 13th depending on how much news there is to report the first week back. Happy holidays to everyone, and a have a safe and happy new year.

Developer calendar

For an up-to-date list of the coming week’s Mozilla project meetings and events, please see the Mozilla Community Calendar wiki page.

Subscribe to the email newsletter

If you would like to get this newsletter by email, just head on over to the about:mozilla newsletter subscription form. Fresh news, every Tuesday, right to your inbox.

While trying to add setting clipboard content support to doh.robot, I encountered a very strange bug and spent several hours of trail and failure without going anywhere. I am using java 1.6 update 11 directly from Sun. Basically, I have two problems both of which are described here: copying HTML data to windows clipboard from java does not work, with the following symptoms

1. when puting data into the clipboard with a RepresentationClass other than java.lang.String does not work properly with any applications (it is the same issue as described in a java bug report, which is supposed to be fixed in java 1.6 update 11)
2. even if you do use java.lang.String as RepresentationClass, the pasted html only appear correctly in IE, not in safari (it contains extra garbage characters), nor in FF (nothing is pasted at all).

The problem as described in the mentioned webpage, is due to buggy support of windows HTML clipboard format in java. One workaround is suggested in the same article by modifying some internal stuffs in the supporting class in java with the source files available for download. However, the provided code fails to run against my java 1.6 (although it does compile fine), probably due to changed internal mechanisms.

Luckily, I tried to run the same code against the next version of java (1.7 provided by openjdk, still in development), and the paste works great in all three browsers. However, this java 1.7 does not provide a java plugin for Safari, nor google Chrome. (only java 1.6u10 and 1.6u11 support these two new comers)

In order to workaround this, I decided to backport the fix from java 1.7 to 1.6. I don’t want to re-compile the whole jre or jdk, I just want to fix this particular bug. The buggy code is in sun/awt/windows/HTMLSupport.class (in rt.jar under java installation folder).

After poking around in the java 1.7 source (grabbed from openjdk), it turns out that file does not exists. However, with some string searching in files, I found out that it is now defined in jdk\src\windows\classes\sun\awt\windows\WDataTransferer.java. After doing some renaming and such, I came up with a HTMLSupport.java source file (which is a direct port of the original file included in java 1.7 source). Aftering hijacking the builtin HTMLSupport, sure enough, everything works as expected in java 1.6 now.

A pre-compiled HTMLSupport jar is available for download, which should work in java 1.6 (may work in previous versions as well).

How to use this new HTMLSupport

If you intend to use java applet (as I do in this case), then hijacking (or BootClasspath trick) does not work for IE: even if you set -Xbootclasspath/p:\path\to\your\HTMLSupport.jar as the runtime parameter in java control panel for java applet, it does not work. It seems IE just simply refuses to look at that configuration and uses the default bootclasspath only.

Short of other workarounds, I do it the brutal force way: replace the original HTMLSupport.class file in rt.jar with the patched one (you can find this file in the jar, it is the only file in there). As this is intended to be used in a virtual machine whose sole purpose is to use doh.robot to run functional tests, so it is not that bad.

Thanks goes to all the authors of the articles mentioned in this post.

One thing to note: the original articile was written in 2003, more than five years ago, and this bug still exists in latest java stable release (which is 1.6 update 11).

Well, I'm back. I didn't mean to go silent for so long, but I've been busy. Although it will be a few months before it comes out, Jan Goyvaerts and I have mostly finished work on our new regex book — stay tuned for more info. During this blogging hiatus I've also attended multiple family reunions, switched jobs, learned a new language (ActionScript 3), put in crazy hours on a new website launch, and about five weeks ago I moved to sunny Baghdad, Iraq for webdev work.

Anyway, now that work is calming down just enough for some breathing room, I should be able to get back to this blogging thing a little more regularly.

Teaser: Relatively soon I hope to release a new version of XRegExp with support for leading lookbehind and other new syntax, as well as a way to easily extend XRegExp with your own, new regex features. w00t!

A quick tip on a very simple pattern that can be used to tell a user who has JavaScript disabled that they have to turn it on.  Place the message you want to show between two script blocks that simply write a div around the message, setting it’s display to ‘none’.  If JavaScript is enabled, the user will never see this message.  If it is disabled, they will see it.

The main advantage of this approach is that there is no flicker waiting for the page to load before the message is hidden.  See the example blow.

<script type=”text/javascript”>document.write(’<div style=”display:none”>’);</script>
You must enable JavaScript to use this site
<script type=”text/javascript”>document.write(”</div>”);</script>

Update: As pointed out in the comment thread, this is the same as <noscript> really, but no harm in having one more pattern out there

      

Due to better 64bit support, we decided to use VMWare instead of VirtualBox. To prevent of installing a gentoo to a VMWare image, I decided to convert the already working virtualbox image (a vdi file) to VMWare (vmdk). Qemu-img is the command line tool for this task, using the following line, I can get a vmdk:

qemu-img convert -O vmdk gentoo32.vdi gentoo32.vmdk

However, this vmdk is not recognized by VMWare 6.5. I guess it has something to do with the fact that the original vdi file is using dynamic sizing (the file contains a 5G partition, and it only has 1.9G data, so the real size for the vdi file is about 2.1G): the converted vmdk is 1.9G, and VMWare reports that it has 2.1G total size.When booting with this image, VMWare fails to read any data from the virtual disk. After tried another time with the above approach, which also failed, it seems I have to find another way. Luckily, VirtualBox comes with a command line tool called vboxmanage, which can do all sorts of operations on vdi files, including converting vdi to raw disk image, so let’s try that:

vboxmanage internalcommands converttoraw gentoo32.vdi gentoo32.raw

The above command will generate a 5G gentoo32.raw file. Then use qemu-img:

qemu-img convert -O vmdk gentoo32.raw gentoo32.vmdk

To convert the raw file to vmdk. The resulting vmdk file is also 1.9G, but this time VMWare recognize it just fine (reporting its real size as 5G). After changing the root device from /dev/sda1 to /dev/hda1, this image can boot just fine in VMWare, with one exception: the network interface eth0 can not be started. More inspecting reveals that “udev renames network interface eth0 to eth1″. This is caused by the fact that one of the default gentoo udev rule (/etc/udev/rules.d/75-persistent-net-generator.rules) will write another rule file which saves the MAC address for each NIC, and sure enough, the MAC address for the NIC in VirtualBox is different from that of VMWare. However, this is very easy to fix, once you know where the generated udev rule is: Open /etc/udev/rules.d/70-persistent-net.rules and remove all rules in this file, save and reboot, eth0 won’t be renamed to eth1 any more.