BUG: Timepicker does not display AM/PM on Ubuntu, Datepicker displays an arbitrary “October”

Datepicker and Timepicker Screenshot

Datepicker and Timepicker Screenshot

I recently noticed a little bug in firefox (I don’t know where this belongs, in “xulrunner” or in firefox code itself), and I dutifully report it here:

My friend built an extension for firefox, and I noticed that the timepicker control (in xul) does not display the AM/PM select, neither does it provide a 24 hour clock. (only on Ubuntu).

I live in India, and so it just shows IST instead of AM/PM (see screenshot)

This problem occurs only on Ubuntu (I have not tried other distros). The same firefox extension was displaying AM/PM correctly in Firefox when running on Windows Vista.

The same problem occurred with the datepicker control: it was displaying an arbitrary “October” between the Day number and Month number. (This too, only on ubuntu).

I have reported the bug at bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=479069

I wonder why this is hapenning.

HOW TO: Guest OS Networking in VirtualBox

I am an ubuntu user and I am a web developer. So what do I do when I need to test web applications on IE6 or IE7? I don’t go to some other computer running windows. I run windows in a virtual machine using Virtualbox.

The only hurdle is: how to reach the host OS network from the guest OS network? I scoured the internet for solutions, and I found one that did it in the first go: so here it is.

Now my life is easier. I don’t trouble my friends by asking them to lend me some of their time. I don’t need to interrupt their counter strike or WoW game. I do it on Virtualbox!

BTW, there is this project called ies4linux – a software to install ie 5, 6 and 7 on linux using wine. I tried it, but it somehow didn’t hit the sweet spot. For those of you who want to try, find it here.

Javascript mousemove Event Brouhaha Resolved

Hey all! I’ve been playing with javascript for some time, and I have something very interesting for my JS brethren out there.

There has been long-standing confusion regarding this big question: “How to get mouse coordinates on a page with the mousemove event?”

My googling lead me to this page that says that its impossible to do this. But this did not satiate my itch, so I did some of my own digging (or scratching, if you please ๐Ÿ™‚ ).

I conclude that while this question has no all-pleasing answer, the task is quite doable (though in a useless scientific-theory kind of way).

This post addresses this question in detail. And I’ll take this step by step.

The mouseover event

This event is supposed to be generated whenever the mouse is moved in the “client area” – the white area where the page is rendered.
This event has 6 sets of properties (in all browser taken together):

  • clientX, clientY
  • layerX, layerY
  • offsetX, pageY
  • pageX, pageY
  • X, Y
  • screenX, screenY

Now, thats the easy part. The major PITA is that not all browsers support all these properties. And, if two browsers support the same property, they don’t implement them the same way!

The only exception to this confusion is the screenX/Y pair: they are available consistently across all browsers, and all do the same thing – get the coordinates with respect to the top left corner of you screen. But then, this value doesn’t really have much use, does it? ๐Ÿ˜

And here’s how the rest of the properties behave cross-browser:

1. Firefox – both 2 and 3

  • offsetX/Y and X/Y pair are undefined. So if you try to read them, you will get “undefined”. No, not even null. Plain undefined.
  • clientX/Y, pageX/Y and layerX/Y all get us the coordinates of the mouse with respect to the top-left corner of the client area, regardless of the padding of ‘body’.
    So whatever be the padding of your page’s body, you’ll always get the same values, no matter what.
    This is kind of standard across browsers too, except that different properties return this value.
  • Now then, there’s the quirk: FF2 does something strange with layerX/Y: it is not equal to pageX/Y and clientX/Y – instead they it is always (1+clientX)/(1+clientY) – God knows why! This is probably because it does not count the border of the client area. But again, defining the client area’s border is like fighting foo.

2. Konquerer 3.5

It is this browser’s implementation that has appealed to me the most.

  • All the properties are defined. clientX/Y, pageX/Y, layerX/Y and X/Y all mean the same thing – the coordinate w.r.t the top-left corner of the client area.
  • offsetX/Y gives the coordinate of the mouse inside the current element, where current element is the element over which your mouse is hovering.
  • A point to note is that offsetX/Yย  gives the coordinate from the outer edge of the border(in case of more-than-1px-wide border) of the element – so margin is not counted, and the padding is considered as part of the element.

3. Opera 9

  • Here, layerX/Y is undefined.
  • clientX/Y, pageX/Y and X/Y are the same as that in Firefox and Konqueror.
  • But offsetX/Y is a different story. It behaves like in Konqueror, but it returns the coordinate w.r.t the top-left corner where the padding ends!
  • Further, the padding region and border region are part of the “current element”, but when your mouse is in, like, the left padding region, the layerX is negative. Baaaad!
  • However, this behaviour is not repeated with the layerX/Y etc for the body – in the case of body, padding’s just as much a part of the client area as is the content.

4. Google Chrome

This browser, thankfully, adopts the konqueror standards. Perhaps that’s because the google guys liked that model too. (That says something about me, doesn’t it? :P)

But there still is one small difference — and I’ve saved that for the last! Noooo… don’t rush down to the end just now!

5. IE 7 and 6

  • Here, layerX/Y and pageX/Y are undefined.
  • clientX/Y and X/Y are the coordinates w.r.t the client area’s t-l corner (yeah, no padding).
  • But then, there’s a glitch (again). In IE, the mousemove event is generated very slowly – only when your mouse crosses an element’s boundary, or you are shaking the mouse rather too vigourously. Perhaps this was intended to be some kind of performance bonus, it is headache for us devs.
  • And, offsetX/Y behaves like in Konqueror, but the event is generated too slowly to really tell whether the padding is being included in the coordinates or not. IE’s weird as ever. Microsoft. Bleah!

I got the same result with IE 5.5 and IE 5, but the testing was not as thorough. Who cares, anyway.

BTW, I did my IE testing on both Windows machines, as well as my dear Ubuntu. I used ies4linux, of course.

Summary

In all, here are a few things to note:

  1. screenX/Y and clientX/Y work in all the above browsers.
  2. Firefox does not support offsetX/Y.
  3. All the rest support offsetX/Y, except that Opera pulls in all the padding shaggywag.
  4. IE has a very lousy “refresh-rate”. Hopeless, really.

Now for the final piece-o-cake:

Q: What happens when you drag your mouse out of the client area?
A: One would expect that mouse tracking should stop, and it does. But, Opera and Konqueror do one additional thing – they track the first point that lands outside the client area. This means that after tracking has stopped, one of the values in the clientX/Y pair (or X/Y or pageX/Y etc) may be negative! So watch out! But again, google chrome does not do this stunt – it does not track any point outside the client area. Nor do Firefox and IE.

Whew! What a marathon! I wonder if all this is any real use at all. Given that you know all this, you still have to do a browser detect to write any “portable” javascript.

I firmly believe that browser detection is bad for javascript – it is bad for the minority of users who use obscure browsers that implement a well-known-browser-compatible standard.

So I guess this info is for just alpha geeks who want such info just for the sake of it. But it satisfies my itch quite perfectly.

So then, Thank you. ยกHasta luego! (bows and exits) ๐Ÿ˜€

Delicious add-on: Yes No buttons swapped




delicious

Originally uploaded by jrharshath

I use the Delicious Official add-on for firefox extensively. I wonder if anyone has noticed this, or reported this to the delicious guys: the icons on the Yes and No buttons in this confirmation dialog are in the wrong place!

Perhaps its because of this: On a yes-no confirmation dialog in windows (yuck!), the Yes button always appears on the left side of the no button. But in linux, its always the reverse.
While writing the addon, if you specify that the button that means should say “Yes” and the “No” one should say “No”, then there won’t be any such glitches.

However, if you specify that the “Left” button should display “Yes”, this problem occurs. The left button is Yes alright, but the icons displayed are decided by the OS. So the icons kind of become OS dependent. Now we don’t want that, do we?

How firefox eats up my system resources

Despite all the cool stuff about firefox, it can voraciously eat up system resources when spiced up with just the right add-ons. When I first noticed this myself, I was pretty surprised: I though firefox was the Best app ever! Now I’ve grown wiser, and I know better.

Here’s how firefox eats up my RAM: and the steep cliff on the graph is the moment I close firefox.

I’ve tried to reduce this stat ever since I got the (horrifying!) pic

For one, I reduced the amount of data firefox would store in its online cache (yea, that means your RAM) by reducing its cache size from 50MB to 20MB (change it from about:config -> browser.cache.disk.capaciy )

I’ve also removed the addons I don’t use, or are redundant. Like, I used to use flashblock, but since I’ve started using NoScript (which also blocks flash), I’ve removed the former.

This brings me to flash. Flash stuff on websites tends to make firefox eat up even more of system resources. It is best to kep flash disabled and enable it only for certain websites (using NoScript or flashblock). Anyway flash violates all known and loved rules of web design anyway. Who wants flash? Go away!

Back to where I left off: I also checked the problematic addons list and removed all addons that have a history of memory leaks. In some cases even a solution for problems was available, like the case of noscript and flashblock.

Well, I’m not complaining. I still like firefox more than I do any other browser. And I am fiercely loyal to it. This is just how I try to coax my favourite (and most frequently used) application from not mauling my RAM every time I run it.