Whilst working for a company obsessed with customer service, I once learned that 95% of customers won’t bother to report a problem, they’ll just go elsewhere.

That figure is probably higher still on the Internet, where anonymity and choice are key aspects of the customer experience.

Support personnel at the Belgian edition of online recruitment website Monster clearly have much to learn about customer service.

Since the last time I updated my profile, Monster has ajaxified, widgetised and fetishised many of its interfaces. Most of them work fine.

However, I wrote to Monster the other day about a problem in Firefox with the tabs in their My Profile page. When I click these tabs, I explained, the content below is supposed to change. Instead, the click event is not being captured by the appropriate script so that the browser is navigating away to an error page.

Here’s an abridged reply from Davide Palaia of Monster Global Customer Services:

Dear Mike Padgett …

First of all, I would like to thank you for putting this to our attention, I will contact the right department and investigate for you.

However I would suggest you to either clear cache and cookies of your FF or eventually, if you still notice some difficulties, download Internet Explorer … [My emphasis]

I rest my case.

This is only a problem, so far as I can see, when you’re using backgrounds on the unfloated element(s), because thr background image or colour will overrun your floated element.

Want to try it? The situation is as follows:

1. Float an element containing either an image or text
2. Continue with unfloated elements so that under normal circumstances they wrap around the floated element
3. Give the wrapped text a background property, such as a background colour or image

The code so far:

/* CSS */
.floated {float: right;}
p {background: #fc0;}
...
<!-- HTML -->
<div class="floated"><img src="/images/tmp.jpg" /></div>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit</p>
<p>Class aptent taciti sociosqu ad litora torquent per conubia nostra per inceptos himenaeos</p>

Up to this point everything’s normal:

So far so good. Now add font-style:italic; to the rule for p.

Here’s Firefox, with no surprises:

But here’s Internet Explorer 7:

The only (il)logical answer seems to be the addition of overflow: auto to the rule with the background.

I was clued in by a slightly different issue with the same fix already discovered long ago. Just to remind you once more, this is IE7 only, folks!

Not for the first time, I was happily authoring CSS and Dreamweaver CS3 crashed. Turns out, it doesn’t have to be specifically CSS, but that was my situation anyway.

The crash

It’s all too familiar: this is DW after all, and those of us who have used it from the start will know the pedigree. But I try to restart the program anyway: it’s 1am and I don’t need this. Nope, fail. Dreamweaver CS3 won’t start on Windows XP. In these times of quad processors and 32-bit colour, has the long-exorcised ghost of DW’s buggy past returned to haunt us?

The following options were available:

• Abuse someone at Adobe
• Reinstall Dreamweaver
• Try to clean out the config files so that Dreamweaver has to create new ones on restart (an old and occasionally successful solution)

And the answer? None of the above.

The fix turned out to be simple, though somewhat obscure. I shall elaborate in a moment, but first I must attribute my source. In August 2007, Adobe Community Expert and author David Powers sussed out this profoundly ugly problem in the Macromedia.Dreamweaver Google Group. At the time, it was undocumented elsewhere and not particularly easy to find with bland keywords in search engines.

The cause of the crash

Apparently, an install of Dreamweaver CS3 (mine is currently v9.0 Build 3481) crashes if you edit a file to exactly a multiple of 8,192 bytes. Not a byte more, not a byte less. The chances of this happening are probably fairly small: to edit a file to the exact size at the same moment that DW does some processing and gets upset.

Don’t believe me? I wouldn’t have either in your position. But here’s what happened: I’m editing a document of any supported format, I’m just about to change a particular value and suddenly it crashes. So I checked out David’s comment above and, lo and behold:

So now what?

If you have this bug, from here it’s quick and easy to escape. Don’t bother trying to do anything with Dreamweaver CS3 because as long as your file is a multiple of 8,192 bytes, you ain’t going nowhere.

Step 1. If you were working within a Site, you can test if this bug was behind the crash

If you were editing your file within a defined Site, read on. Otherwise, you can skip to 2.

In Windows Explorer, temporarily rename the folder that contains your Site, so that Dreamweaver CS3 starts successfully, asking you to Manage Sites… because of course it can’t find your original folder.

If you were to point Manage Sites… to the new folder name, Dreamweaver CS3 would crash again, so just exit the app for now. You can now be pretty sure you’ve encountered this filesize bug.

If DW doesn’t start properly after this step, then you have some other problem and I’m sorry your visit here didn’t help.

Step 2. Edit the file that caused the crash outside of Dreamweaver CS3

Next, in a different text editor such as Notepad, increase the filesize of the file that you were editing when DW crashed – just by adding a bit of whitespace, for example – and then resave it. You could also decrease the file size by deleting whitespace, but of course you risk repeating the bug when you work on the file again later or indeed, you might not have anything to safely delete, so I’d recommend increasing instead.

Now, having altered the file, be sure to check that your filesize is indeed no longer a multiple of 8,192kb.

If you were working within a Site as described in Step 1, you can now rename the folder of your Site back to its original name in Windows Explorer.

Restart Dreamweaver CS3 and you should be back in action. I hope it worked for you too!

Afterthought

As you can probably see, there are quite a few satisfied customers in the Responses below, from Denmark to Chile. So why not let me know if you had this problem too and if your situation was a little different, please add to the knowledge.

And finally, this incident jogged my memory of another oddball software behaviour I encountered once in the early days of Office 2007 for Windows, because it too was about processing bytes and coming out with the wrong result. Check out this anomaly with Excel 2007: if you multiply 850 by 77.1 you get 100,000. The real answer? 65,535 of course, a juicy, meaningful number for aficionados of binary computing! [15 April 2008: I tested this again recently and it appears to have been patched - Mike]