Pixelastic

I own a Sansa Clip+ as my mp3 player. It's really small, has great audio quality and combined with a 32Go microSD card plus the internal 8Go, it's enough to hold almost all my music library.

As with any mp3 player realeased nowadays, you can browse your files using mp3 tags. I don't really like it and feel limited in my browsing. As I'm listening to a lot of movie soundtracks I have a pretty long list of artists with only one song attached.

Fortunatly, the Sansa also allows you to browse by folders, which is rare enough to be highlighted.

So far so good. Except that I've discovered a little bug a few days ago in the way folder navigation is done.

I had two folders named Soundtrack - Games and Soundtrack - Movies. Each were holding a dozen albums. In each of those folders I had subfolders sharing the same prefix, like Hitman Contracts, Hitman Blood Money or Kill Bill and Kill Bill volume 2.

When browsing my music folder on the Sansa I noticed that the Soundtrack - Games folder had disappeared. I check the SD card in my computer, and it really was there.

I finally discovered that all the Sountracks - Games content had been merged in Soundtracks - Movies resulting in one big directory instead of two smaller ones.

My second discovery was that all my Hitman sub folders were also merged into Hitman Contracts, and my Kill Bill music was in Kill Bill volume 2.

It seems that when multiple directories shared the same prefix, all folders will be merged in one whose name is the last in alphabetical order.

I'm not the only one in this case, I saw a similar report on Sandisk forums, but the bug seems erratic. Folders does not always get merged if sharing a prefix.

As a temporary fix, waiting for a regular fix in a firmware update, I'll update my folder tree to use Soundtracks/Games/Hitman/Contracts and Soundtracks/Movies/Kill Bill/Volume 1 but this is far from optimal.

Last Friday, just before turning off my computer and going home, the cake project I'm working on was displaying a scary Fatal error: Class 'Controller' not found in /var/www/project/app/app_controller.php on line 5

Today, I'm getting back to work and here's what happened. After a morning of trial and error, I finally reverted back to a previous svn commit, then re-updated to the latest one and it seemed to solve the issue.

But later on the day, after another update, it started bugging again and the error message wasn't very helpful.

After much googling, this bug report gave me a hint : I had new models but didn't create the corresponding tables. Strangely, creating the missing logs table for my Log class solved the issue.

Hope this blog post will be usefull for anyone else struggling with this error message.

Edit : The issue discussed here has been fixed in Firebug 1.9a2

It took me a whole day to track this bug down. At first I thought something was wrong in my request, I tried to replay it using Firebug and I kept hitting a "malformed request" error.

Debugging it in reverse order, using Wireshark and other tools I finally came to the conclusion that my request was indeed valid.

So what ?

The guilty part was indeed Firebug. When I ran a simple POST request from Flash, and inspect it from Firebug, I could spot that no Content-Length nor Content-Type headers were displayed in the "Headers" part. I then saw that the "source" part of the POST tab contains my missing headers. What was that ?

HTTP POST Request are supposed to be split into two parts. First part are the headers, each separated by a \r\n. Then, after and empty line was the POST raw content. Seeing that my headers gets mixed up with the POST data I thought that the request was malformed and a \r\n was added too early.

I checked with Wireshark and with PHP on the back end, and no, the request was indeed absolutly valid. Wireshark did not show any \r\n that shouldn't be there and PHP correctly parsed my request. The only issue was the details displayed by Firebug.

So it's a display bug ? I can live with it.

Well, actually, it's a little more than just a display bug. It kind of blocks my usual debugging workflow.

To debug an XHR request, I don't usually restart the whole page request just to debug one of the inner request.

The Firebug ability to "open request in new tab" is a time saver for me. I can play and replay the same request over and over until it's debuggued.

But with this bug, I can't use this feature. Opening the request in new tab will not send the slipped headers, and will instead send them in the POST source, resulting in a corrupted posted data.

I've posted an issue on the Firebug bug tracker. I hope it will get resolved soon. Until then, I'm using Live HTTP Headers to capture and replay the requests I need to debug.

Update

Seems like the bug come from Firefox internals and not Firebug. More details on this post.

Edit : Seems to be resolved in Firefox, will be available in next release (8.0 I guess).

Sometimes you encounter bugs that smacks you in the face with their strangeness. And even when you defeated them you still have this sour taste of puzzlement.

I encountered one of them today.

While testing in a local environment and doing POST requests from Flash to a distant cake app, I could get the request just fine.

But when uploading the SWF on the server and embedding it in a Facebook App Iframe, the POST data seemed corrupted and I couldn't get it.

Replacing the distant POST call to a local one (removing the whole http:// part) fixed this strange bug.

So we ended by adding a check to see if we were online or local and make an absolute or relative call depending on the environment.

So far, no more issues.

IE8 has a strange bug (what bugs aren't strange in IE ?) when dealing with :after and :before pseudo-elements.

I was adding a nice looking arrow after one of my elements using :after. I wanted this arrow to only display when my element was hovered, so I wrote the following code :

<a href="#">Example</a>

a {
	position:relative;
	display:block; 
	height:30px;
}
a:after {
	position:absolute;
	content:"";
	top:0px; 
	right:-15px;
	width:15px;
	height:30px;
	background:url(arrow.gif) top left no-repeat; 
	display:none;
}
a:hover:after {
	display:block;
}

As you can see, nothing too fancy. I positionned my arrow using an empty :after element and a background image. I defaulted the arrow to hidden, and only show it when hovering the element.

IE in action

It does work pretty well in moder browsers. It also seems to work on IE8. When you hover the element in IE8, the arrow gets displayed. But it does not gets hidden when you stop hovering it.

There's a kind of ghost element that keeps getting displayed. It gets removed if you directly mouse it, or scroll your page, or alt-tab, etc. This clearly is a display artefact.

To counter this I had to write it in an other fashion (less readable in my opinion). Removing the default a:after rule and adding all properties to a:hover:after :

a {
	position:relative;
	display:block;
	height:30px;
}
a:hover:after {
	position:absolute;
	content:"";
	top:0px;
	right:-15px;
	width:15px;
	height:30px;
	background:url(arrow.gif) top left no-repeat;
	display:block;
}

Update

It should be noted that more generally, I gets confused and create ghost elements and styling when we try to update the :after/:before properties based on a rule selecting its parent.

There seems to have a little lag/delay before the properties gets applied, and most of the time they do not.

This <noscript> tag on IE7 is making me crazy. Here are some "interesting" facts about it :

No content through Javascript

You can't get its content though javascript. It can be targeted but neither .innerHTML nor .textContent is set. It does not have any .childNodes either.

Gets displayed even when scripts are enabled

If you set noscript { display:block; border:15px solid red;}, it will get displayed even if Javascript is enabled. But with no content inside, you'll only have borders and background...

Styling it anyway

If you want to style it, just add an inner element and style this one :

<noscript><p>Lorem ipsum</p></noscript>

noscript p { background:blue; }

Disabling Javascript on IE7

If you want to disable Javascript on IE7, you'll have to go to Tools > Internet Options > Security > Custom and setting the "Enable ASP scripts" to No.

Yes, this doesn't make any sense.

It seems that if you're creating a fixture for a model that uses an unconventional table name, the CakeTestFixture does not manage to correctly create the needed table when your test starts.

In fact, it will try to insert the fixture records into the right table (the one defined in $useTable), but won't have created the table beforehand.

In fact this is because it will correctly rely on the model $useTable property when inserting records but will try to guess the table name based on the model name when creating the table.

Anyway, the quick fix I've found so far is to define the $table property of your fixture to match your model $useTable.

class Client extends Model {
	var $useTable = 'users';
}

class ClientFixture extends CakeTestFixture {
	var $table= 'users';
}

I've filed a bug report as well as suggested a fix to allow cake to automatically use the correct table.

If you try the following code in Opera 10.51, you'll have some weird rendering bug :

<style>
	.test:after {
		content:"This should be on red background";
		background:red;
	}
 </style>
 Text input : <input type="text" value="I'm unstyled" class="test" />

The generated content is added to the page, but the background color isn't rendered. Worse, the input lose all styling, it does not have a background color nor borders anymore.

The same effect also apply to every input (radio, checkbox and password).

On a select tag, the generated content correctly have it's background color, but still lose all styling.

On a textarea, the styling is gone too, and the background color is here. Well, sort of, it is actually cropped after a while and the end of the text is on transparent background.

I sent a bug report to Opera about that.

I just ran into a strange behavior on Safari 3 (Win). I'm not quite sure what caused this problem, but I tracked it down to one CSS rule.

The thing was that I had an input field that moved whenever I tried to focus it. It jump 3 pixels up whenever I gave him focus. I had never seen that before.

I finally managed to track it down to the padding:2px 0px 5px 0px; declaration. I exploded it in four (-top, -right, -bottom and -left) and it seemed that it was the padding-bottom:0px that cause the bug.

I finally rewrote my css (in three lines instead of one) and moved to other things.

I post it here as a reminder, and hope it could help someone.