For historical reasons, the value IDL attribute prefixes the filename with the string “C:\fakepath\”. Some legacy user agents actually included the full path (which was a security vulnerability). As a result of this, obtaining the filename from the value IDL attribute in a backwards-compatible way is non-trivial. The following function extracts the filename in a suitably compatible manner:

function extractFilename(path) {
  if (path.substr(0, 12) == "C:\\fakepath\\")
    return path.substr(12); // modern browser
  var x;
  x = path.lastIndexOf('/');
  if (x >= 0) // Unix-based path
    return path.substr(x+1);
  x = path.lastIndexOf('\\');
  if (x >= 0) // Windows-based path
    return path.substr(x+1);
  return path; // just the filename
}

(source, please look at the URL)

WHAT We Guck!!?

At the same time, Firefox seems to be interpreting the title of this post literally, and instead of C:\fakepath\, I see C:akepath in the tab title–because it is showing the escaped f (i.e. \f). A nifty square with (0 0 0 C) shows in the browser window title area instead of the \f…

Update, later: Chrome does it too, as well as Chromium, and Opera.

Another update: maybe it’s a WordPress thing? I just wrote a test html file with backslash on its title and it’s shown properly on the tab title. Hum ho.

Glitches, glitches–they are everywhere!

Or more exactly, the double spacing that I was seeing, instead of just a single line as in the original!

Initially willing (or expecting) to put the blame on me, I examined my back-end code first, but there is nothing dealing with double spacing or “Windows spacing” correction, such as automatically replacing \r\n with \n only.

I then remembered that when I developed this section a year ago I was using Chrome as my main browser, so I wondered if it was a Firefox-only error that had slipped thru back then. Therefore, I repeated my test with Chrome: opened a FILE_ID.DIZ with gedit, copied the text and pasted it to the corresponding textarea. Clicked on save… and the result came out OK! Simple single line-endings were received by PHP, as one would expect.

So it’s a Firefox thing then, I thought. Not so fast, it can still get more bizarre. But before I get to that, let me show you a little piece of test code I wrote to ensure nothing else was interfering in the process:

(you can download it from here, in case you want to test it too)

What the test code does is simply highlight ‘\n’ characters with red, and ‘\r’ characters with green, so I can visually see what has been added. It’s not exactly like a full-grown hex editor, but it’s more practical for testing in the browser.

Then, if I use the following test text (please ignore the fact that some characters are garbled because of the encoding–though if you don’t understand Spanish it should all look fine to you!):

When run with Firefox, I get this:

(notice the double spacing: there are double sequences of \n\rs)

And with Chrome it’s fine:

And here comes the fun: when I copy the text from Chrome and paste it in Firefox. What do you think will happen? Will it double the space when I press Submit?

No! This time it works properly! Crazy! Or what? Well, I have made more tests to try to pinpoint what’s happening.

Test one: copy from a txt file that I created on this computer (so it’s all Linux line endings), paste into Firefox: WORKS. Paste into Chrome: WORKS.

Some guy reported (for another product) that copying from Gnome terminal or gedit to Firefox got him strange results, so I tested the Gnome terminal bit too. Works on Firefox and Chrome: no extra line endings.

Test two: I converted the original text file from Code Page 437 (the old MSDOS encoding) to UTF-8, and opened it with gedit, and pasted it into Firefox: DOESN’T WORK! Double line spacing again! I guess a \r is a \r is a \r, no matter what the encoding! (fortunately).

Test three: Opened the file with GVim. Copied everything and pasted into Firefox: WORKS. Single line spacing as expected.

Conclusion?

Before drawing up a conclusion, I’ll summarise the facts:

1. In all the tests that “fail”, the copy-paste source is gedit, and the content is a file with MS-Dos line endings.
2. It only fails with Firefox

So this is what I think is happening: gedit is getting confused by the MS-Dos line endings, and “something is wrong” in the data it puts in the clipboard when I press CTRL+C. Then Firefox gets sort of crazy when it gets those “wrong” characters or whatever gedit is storing in the clipboard, and tries to correct it… but ends up adding double the required line spacing.

On the other hand, Chrome seems to be able to “recover” from possibly malformed data, and proceeds in the normal way we expect: not duplicating content.

However I’m not too sure about this theory. I’d like to see the raw clipboard contents (this time, with a proper hex editor), to find out what is in there, but I haven’t been able to find any program which does it. And I’m not sure I want to start digging X-Clipboard protocol RFC’s or whatever it is that they use for their specs in order to find out how to communicate with the daemon which is listening to CTRL+C/CTRL+V key presses.

Do any of you have any pointer? Any idea? (other than telling people to not to use gedit!). A server-side solution is not exactly the best idea, since although I can detect whether the user is using Firefox, I don’t have any way to detect if a text was pasted from gedit! And blindly replacing groups of \r\n\r\n with just \r\n won’t work either: what if the text file indeed contains two carriage returns?

Decisions, decisions!

Update: found a gedit bug which might be related to this issue!

I’m not sure about the horse power of current mobile platforms for running browser applications, though… And what’s with the pixelated, blocky icons? Is it because games are assumed to be blocky by design? Is no antialias the new antialias?

~

Silverlight vs HTML5 – was a fight to be fought rather sooner than later. Microsoft seems to me like they’re piloting a giant ship which takes ages to change direction. Only they don’t know which direction should they head to: with native applications being less relevant nowadays (at least desktop wise) it seems silly to keep working on new GUI layers and systems in Visual Studio and etc.

~

HTML5 Audio data exposed with Firefox 4 – more Mozilla good news. There was some support for FFT data reading a few Firefox beta builds ago, but they weren’t officially sanctioned until now, so experimenting with that was a bit risky. The video shows also audio data being manipulated too (not only read) with real time filtering… this has huge potential for projects such as jranular :)

I also find of capital interest that all these new audio features have been developed entirely outside Mozilla, as the main author details in his blog. +1 for open source ;)

Oh, and in mrdoob’s words:

Really hope Chrome implements Mozilla’s Audio Data API. Other browsers won’t have other choice then :D http://audioscene.org/

~

Zhook, a simple HTML5 based ebook format. Very sensible idea — specially if you’re reminded that most of the platforms at which ebooks are targeted use the very capable WebKit as their core component for dealing with HTML:

iOs, Android, webOS, Symbian — all use the WebKit rendering engine. That’s four broad global mobile operating systems that basically define the walk-around go-anywhere Internet today.

I looked at the ePub format a few months ago and well… let’s just say it discouraged me :-P

~

Finally, more Mozilla goodness! It seems Firefox’s nightly builds using the superawesome JägerMonkey javascript engine are already available. I’ve tested one of the builds they provide and the latest version from Firefox repository (compiled in my computer), and I’ve seen huge performance increases with mrdoob’s plane deformations experiment.

It still can’t beat Chrome and some of the other experiments run horribly slow, but it’s getting dangerously close, as testified by their are we fast yet? website. Well done, Mozilla people!

And that’s a pity, because I find the inline mode way more comfortable for users: rather than having to click a button in order to open an overlay with the calendar and then finally select the date, they can simply select the date in the calendar, without worrying about anything else.

So I devised this simple function that when run over DIV elements attaches the corresponding inline d date picker to them, and also creates a hidden input element for each DIV, which will hold the selected associated date.

This value will be updated automatically whenever a new date is selected in the calendar (because we bind to the select event). When the form is submitted, the value for the inline date picker is submitted too, thanks to the hidden input element :)

You would use it like this:

It then would use ‘.calendar’ as the selector, and jQuery to look for matching elements, creating the inputs and binding to the select events.

For this to work properly, you need to specify two attributes in each DIV element:

• name
• value

Therefore, a proper DIV, apt for being datePickerized, would be the following one:

and the form field would obviously be startDate.

I’m uncertain about the validity of these two ‘new’ attributes in DIV elements. The W3 validator is definitely not happy about them, and spits two unmerciful there is no attribute “name” and there is no attribute “value” errors, yet it works with Firefox and Chrome, both allowing me to manipulate object attributes at will.

HTML5 makes room for custom attributes, but their names should be prefixed with “data”. So these attributes should be renamed to “data-name” and “data-value” respectively if I wanted them to be valid HTML5 (although I’m still using a transitional XHTML doctype for this project).

All in all, a tremendous hack, but very practical. Hopefully HTML5 support for time/month/datetime/date inputs will get better in the future (currently only Opera supports them, as Mark Pilgrim dutifully points out).

Meanwhile, transgression is a must.

But I managed to find how to build it from source. It turned out to be quite simple, it’s all in one page. With the Ubuntu instructions only, it gets reduced to this:

And to update:

It didn’t take much time to build (less than 20 minutes). I can’t remember how much time did Chrome take the last time I tried, I should repeat it if only for curiosity sake.

And now I have a custom build, aptly named Minefield!

Still, it’s slower than Chrome in the tests I have ran (Javascript intensive tests, mostly Mr.doob‘s javascript experiments). What a pity, the promised speed improvements made me want to go back to Firefox :-(

In their defence, it built without complaining about any missing and/or almost impossible to fulfill dependency. Which is something you can’t say about every open source project, unfortunately.

I’ll keep an eye on it, now that I know how to get my own builds…

UPDATE: if the build breaks for whatever the reason and you get errors such as these:

just delete the objdir-mozilla directory and try with make again.

Another solution is to delete .a files from the build directory: