java.awt.Desktop open() fails silently without exception

Problem / Bug:

For the last one and a half day I have been investigating a very curious problem. On one Windows XP machine here on our company network (my machine) the following line of code fails without any exceptions thrown:

java.awt.Desktop.getInstance().open(new File("C:\\test.txt"));

The test.txt file is there. It opens normally when I double click it. Furthermore I can open it from Java using the (platform specific) Runtime API code:

Runtime.getRuntime().exec("rundll32 url.dll,FileProtocolHandler C:\\test.txt");

Also, if I invite some other user to log on to my machine and run the test application, it does work for him. I have created a new (local) account and for that account it did work. If i log onto some other machine with my network account and run the test application there, it works normally. Only on this specific machine with this specific account does the problem occur.

Continue reading

WebKit Breaking Float Bug

Update: After being fixed in WebKit, this bug has resurfaced in Blink. Read the follow up post.

I found a pretty big bug in WebKit today. It seems like such a basic scenario that I can hardly believe that no one found it before… and maybe they have but I couldn’t find an open issue on the WebKit bug tracker that described it.

The bug involves a floated div containing an inline element (a span in this case, but I confirmed this also for label and input) and another floated div. The inner floated div breaks to the next line, even though it shouldn’t.

This is the HTML markup for this bug scenario:

<div class="outer">
   <div class="inner">Float</div>

This is the stylesheet:

.outer {
   float: left;

.inner {
   float: left;
   margin: 0 8px 0 0;

This is the expected result:

Float Breaking

This is the actual result:


I have to say I was a bit surprised by this bug. I consider WebKit a very strong browser with excellent standards compliance, being on the cutting edge of web standards. WebKit was one of (if not the) first browsers to pass the Acid3 test for example. So for such a basic scenario to fail is a bit of a disappointment.

Suggested fix
It seems this bug can be fixed by changing the inline element to a block level element, but this has to be done in markup, just a CSS rule display: block won’t help. Another possible fix is removing the float: left rule from the outer container and replacing it with display: inline or display: inline-block.

Repro and bug report
I have created a demonstration page on my personal webspace that demonstrates this bug and reported it on the WebKit bug tracker. I hope they will fix it soon because it makes for yet another of those browser inconsistencies that makes our lives as web developers difficult.