I've never been so irritated!

It also affected the Microsoft Virtual Earth MapControl, so if you use the VE MapControl for a mashup, your Firefox 3 users are going to be affected by this issue.

The issue? It has to do with a mouse event's .pageX and .pageY properties. The values of those properties are supposed to report the "page" position of the mouse cursor, relative to the upper-left corner of the HTML page. You can think of it as the absolute (x,y) of the mouse cursor.

The nice thing about .pageX/Y is that serves as an easy way to get the mouse position, regardless of how much (or even if) the browser window is scrolled.

Contrast .pageX/Y with .clientX/Y: the latter reports (x,y) coordinates relative to the upper-left corner of the browser window, so these values will be affected by browser scroll position.

Anyway, at this point, you're probably thinking that I'm going to tell you that Firefox 3 reports the wrong values for .pageX/Y, and that that's the bug. It's not that simple though (again, I admit this is a somewhat obscure bug).

Most of the time, Firefox 3 reports the right values for .pageX/Y, but there is one case in which it doesn't.

Manually Dispatching Events in Javascript

A while back, I wrote a post about Re-routing events in Javascript. In it, I explain how to create an event and initialize it with myEvt.initMouseEvents(..) (which takes a boat-load of parameters).

Of all those parameters sent into .initMouseEvents(..), 4 are of particular interest: .screenX, .screenY, .clientX, and .clientY.

Notice that .pageX and .pageY are not in the list. You don't get the ability to pass in .pageX/Y when manually creating/dispatching an event in Javascipt. Presumably, the values for these properties are computed based on .clientX/Y and the browser's scroll position.

So for example, if you initialize a MouseEvent with .clientX = 200 and .clientY = 300, and if the browser is scrolled 50 x 75, then your event's .pageX and .pageY values will be 250 and 375 respectively.

Oops! I mean, that's what the values should be.

The Bug

Firefox 2 actually gets it right, but Firefox 3 doesn't.

When you're manually dispatching a MouseEvent in Firefox 3, the .pageX/Y property values will always be equal to the .clientX/Y values, regardless of browser scroll position.

As I previously mentioned, this affects the VE MapControl, so it's easy to see the issue in action. Just use Firefox 3 and point your browser to http://maps.live.com. Now make your browser window small enough to cause scroll bars to appear. Scroll the browser window by some amount (doesn't matter how much) and try panning the map. You should see the map "jump" during the initial pan. The amount it "jumps" is going to be equal to the amount by which the browser window is scrolled.

The Fix

Microsoft has a work-around for this issue that is going to be released with the next version of Virtual Earth, but if you're a mashup dev using the VE MapControl, I've got a solution that you can use right now, and it goes like this:

Just include the preceding code snippet anywhere in your HTML page. The code is pretty straight-forward and just relies on the fact that Firefox (and others) have the ability to define getters through the use of .__defineGetter__(..).

The .pageX/Y properties are read only, but it turns out that the browser will let you redefine these getters, thereby overriding their return logic. Since the .clientX/Y properties appear to always report the correct value, all we have to do redefine the .pageX/Y getters to use a combination of .clientX/Y + .pageX/YOffset.

In other words, we've redefined .pageX/Y to always return the position of the event (in our case, the mouse cursor since we're dealing with MouseEvents), relative to the upper-left corner of the browser window + the scrolled position of the browser -- what it should have been all along!

This code doesn't hurt IE, as it won't execute in that browser, and it doesn't hurt Firefox 2 or other browsers that understand the code either, because the logic we've defined for the getters is going to be essentially the same as what the browser would have done natively anyway.

I'd like to file a bug to Mozilla on this issue, but I haven't a clue as to how one goes about doing that. If anyone knows (or wants to do it for me), feel free to speak up!

Enjoy the fix!

Comments welcome.

I just noticed the other day that his latest post gives some props to my Emulating CSS word-wrap for Mozilla/Firefox blog post, but his version adds some much needed cross-browser support for browsers I neglected.

Nice One, HedgerWow!

Besides the new theme (on Windows) being a little bland, FF3 does not disappoint!

So I was monkeying around, and I decided to write a function to determine if a string were a palindrome. This is not a very difficult problem, but it might make for a descent introductory interview question (one of those questions you'd ask to rule out the truly inept).

With problems like this, I'm mostly interested in two things:

1. Writing the function in a clever way, so as to achieve the least amount of code possible
2. Writing the function in the most efficient way possible

Now, if it were Ruby, writing the clever solution (which might also happen to be the most efficient solution in that language -- not sure) would be ridiculously easy:

That's so trivial, it's probably not even worth writing.

But Javascript doesn't have a .reverse() method on strings, so you have to take an extra step (still pretty easy though):

Split the string into an array, reverse the array, and then join it back together. Since this is all native Javascript stuff, it turns out to be reasonably fast, though one might expect you could do better.

For grins and giggles, I decided to see how a manual solution, where I compare characters starting at each end of the string and work towards the middle, would compare:

This function will probably fail quickly, so that's good, but it also turns out to be generally faster than the split/reverse/join version. It makes sense, since you're going through the string only one time and twice as fast as normal since you're traversing from both ends at the same time.

Can you do even better though? Maybe. At least in Firefox you can, and quick tests seemed to confirm across other browsers too (but I didn't test extensively).

What if we split the string in half, and only reverse half of it. Then we can compare the first half with the original half:

The idea here is just split the string in half, reverse one of the two pieces and compare them. For example:

TOOT: splits into "TO" and "OT." Reverse one of them, say the second part ("OT") and compare.

If you've got a odd number of characters, you can ignore the middle most character:

RACECAR: splits into "RAC" and "CAR" (ignore the "E" in the middle). Reverse the second part ("CAR") and compare.

As it turned out, this seemed to be faster than the other two methods. Not by orders of magnitude, but not insignificantly either. Here are the number from Firefox, running each function 10,000 time on the string "gohangasalamiimalasagnahog" (go hang a salami, i'm a lasagna hog).

• (Traverse from both ends): 797ms
• (Split/Reverse/Join): 969ms
• (Compare halves): 640ms

Of course, numbers varied slightly during each run, but overall the they were consistent relative to each other.

So there ya go. Nothing in particular I wanted to point out here; just found it interesting and thought you might too.

Think my code sucks? Got a better solution? Say so in the comments (you won't hurt my feelings).

I'm going for something very minimalist this time around. In fact, the name of the theme I'm working on is "Less Is More."

Since I've recently installed a Theme Preview Plugin for Wordpress, I thought I'd leverage that to allow my readers to get a sneak peak of what the new theme will look like.

Simply point your browser to: http://blog.stchur.com/?preview_theme=less-is-more.

Feel free to offer feedback on what you like / don't like, but please remember that it's not done (should be done enough though to give you a basic idea of where I'm headed).

For those of you reading from an RSS reader, come on over and check out the blog the "old fashioned way" for a change, so you too can get a sneak preview of the next Incoherent Babble theme.

Either way though, I don't have an answer to post as I promised I would, but not to worry... I have something better: another puzzle!

This one I heard on NPR's Puzzle Master, so I know it is legit:

It's not a trick question, and there is a simple and elegant solution to the puzzle.

Display the answer

In case you're wondering, I heard this in the car listening to the radio, and I'd estimate that I drove about 5 miles or so before the answers came to me, so I'll guess that that was about 5 minutes. How long did it take you to solve?

Comments welcome.

So what's the strategy?

Now I just heard this problem, and I've only put minimal thought into it so far. I will post back with the "official" answer in a few days, but before I do, I thought it would be amusing to entertain some of my quick responses, all of which (based on the problem as it was given to me) are completely valid:

My first solution:

Each prisoner who enters the room takes off one shoe and leaves it behind (while also throwing one switch as per the rules). When a prisoner enters the room and sees 9 shoes, he'll know he is the 10th prisoner.

My co-worker then replied that the prisoners don't have any shoes, or any clothes of any kind; they're completely naked.

My second solution:

Each prisoner who enters the room spits a giant loogie onto the ground (while also throwing one switch as per the rules). When a prisoner enters the room and sees 9 loogies on the ground, he'll know he is the 10th prisoner.

My co-worker then replied that the loogies will dry up and you won't be able to see them because the guard will wait a very long time between bringing each prisoner into the room.

My third solution:

Each prisoner who enters the room will leave a giant poo on the ground (while also throwing one switch as per the rules), and when a prisoner enters the room and sees 9 piles of poo, he'll know he is the 10th visitor.

At this point, we were all laughing too hard to have any further intelligent discussion on the matter.

But I do plan to think about this and report back with a "real" solution. I have a few ideas already, but I don't have sufficient time to get them into words.

If you'd like to post an answer, you're welcome to do so.

Anyway, since the current beta release of Gimme is "Caspian" I figured I'd do a post today in honor of Gimme and the movie (ok, it helps that I also have something worth writing about too).

So anyway, on to what this post is really about: enhancing Gimme.

Not too long ago, Shaun Inman wrote about his proposal for CSS Qualified Selectors.

It's a good idea; I've actually had the same idea and thought briefly about making it part of Gimme's core CSS selector engine. Only, in my model, I have the left-hand-side and the right-hand-side of the < symbol switched. It feels more natural to me that way, because in most CSS selector rules, you can simply look to the far right of the selector rule and know what type of "thing" you're going to be selecting.

Thus, I feel that this:

feels more natural than this:

But this is just details; the idea is the same either way.

So anyway, after Shaun published his idea, John Resig chimed in and mentioned that jQuery supports this already via pseudo :has(..).

Well that's pretty cool, but since Gimme is my library, naturally, I feel compelled to make sure it stacks up against the competition, so I thought to myself: "self, can Gimme do this?" to which a mental reply came back "No, remember? You decided no to implement it."

And I would have just left it at that, because after all, I decided not to implement it for a reason (and I figured that's where I would leave it).

But then, today, my officemate surprised me by asking "Hey, I have a question about Gimme. I'm working with a page where I need to select a <table> element that has an <h1>. Can Gimme do this?"

Well crap! What are the odds that this would come up again so quickly?

Not being one to disappoint, I said "You know what? I decided not to implement it, but I did put significant effort into making Gimme's selector engine extensible. I bet we can write an extension really easily."

So a few minutes later, we came up with this little gem:

Which means you can now use Gimme to do something like:

Unlike what John did, I didn't bother to map this back to the < symbol. I thought about it, and you could do it easily enough, but the more I think about it, the more I like how :has(..) reads.

It's not likely that I'll make something like this part of the core Gimme library unless it start popping up everywhere. It comes up occasionally, but not enough to warrant making it part of the core (at least, not enough in my personal experiences so far anyway).

So there ya go! Think of this as edition 1 of "Gimme can do that too" with (hopefully) many more editions to come.

Comments welcome.