from a social perspective.com

.. at least when combined with Firefox.

To make a short story long, here’s the full story :p
The last few days at work has been a battle of the rare and unpredictable.
A weird bug in our latest project made my team go crazy (you know, the BAD kind of crazy),
and it was a Firefox only bug. oO

It started off when our “report this” feature returned double reports, one with the POST based (non-required) input, and then another one with only the GET variables (id, required value).

This got us all fuzzed and put our brains to the test. Loading our favourite Web debugger tool (firebug anyone?), we saw that Firefox added another GET request for each and every page on our site. That was odd, very odd.

Searching for an answear, we started checking all the pages, each and every one, and it appeared that the double requests happened on all pages, but only when the user was logged in.
So naturaly, we started looking at the login process. Session management anyone?

And if you read the title right, the session road was a dead end road.. a long and tidious dead end road that is..

And after a few hours with firebug, http header monitor, calling the hosting company, and all that fuzz… I updated our user-navigation menu, adding an icon where the src attribute was empty, and guess what.. Suddenly, NO MORE DOUBLE GET REQUESTS!

So that was it, an empty src=”" made calls back to the same page (much like a missing action attribute for forms or empty action=”" loads the same page on submit).

[ratings]

At work today I was striving with IE7 and absolute positioning.
It seems like IE7 has a default of “background: transparent;”, and takes it a bit more literaly than we’re used to..

So if you set an element to cover another with absolute positioning, all events (onmouseover, onmouseout, onclick, etc) is passed on to the underlaying element. That is, unless the overlaying element got a background other than “transparent”.
A color value, image, or transparent png with at least 1% opacity works, but it has to have SOME opacity.

It is not the first time I’ve run into this problem, and I’ve always solved it by adding a semi-transparent png with 1% opacity of either white or black. But this seems like a dumb hack, having to add more images and so on.

But today I discovered that setting an non-image value for the image url() (like url(undefined)) as background works the same way as adding a background-color or a png with opacity 1%, and thus removing the transparency from the element.

The url() cannot be empty, it has to have SOME value, like “undefined”, “test”, “foo”, or whatever suits your needs:


/* This will work */
#foo {background: url(bar);}

/* This won't */
#bar {background: url();}


So there you go, now the element has a transparent background, while not passing the events through to the underlaying element
[ratings]