Yafumato Development Log

Ye Olde Firefox Bugs

Internet Explorer has the lion’s share of browser-specific problems, but I have come across a couple of Firefox bugs while developing Yafumato. I’ve already posted about the IE problems that I’ve encountered, so in the interest of fairness I will now discuss the Firefox issues.

Under certain conditions Firefox will not resize a table when content is dynamically added to it (Bug 287620). This bug affected the old, tables-based version of the messaging page. I can’t venture to say what the conditions are, but a new row containing a message might get pushed outside of the enclosing table and even off the bottom of the screen when appended to the page. A screenshot of the problem is below, where you can see the messaging text overlapping the border of the table that contains it.

Bug 287620 is not longer an issue with the DHTML window interface, but now there is another. Bug 167801 details problems with text area cursors when a text area is above another element. When the text area of a chat window is positioned above the message content of another chat window, the text area cursor is not visible. The screenshot below demonstrates the problem – only the part of the cursor that is not above the message area of the chat window below it is can be seen. This is the case even if the chat window below is not open and therefore not visible. However, if the lower chat window is minimized (which explicitly hides the message content), the problem does not occur. I also find it strange that the cursor is visible if it is above the portion of a chat window containing the text area that belongs to that window.

Another quirk is that if a bottom of a chat window is above another window and the text area of the lower window has focus, the cursor shows through. This occurs in both Firefox and Internet Explorer. This would seem to be related to the oddity noted above.

So, there have been a few Firefox issues, but one thing that helps is that these bugs are documented in a publicly accessible bug database. Internet Explorer has no such database, at least not for current and past versions. There is a bug database for IE 7 Beta, but it requires a Passport account to view it.

Internet Explorer Sux0rs

Sorry for the inflammatory post title but, given the number of problems that Internet Explorer has caused me, I think that it is justified. During the testing the Kidd release I came across many many Internet Explorer glitches, some were fixed before release while a few others are still pending. The issues are annoyances rather than showstoppers, and this release is such a big improvement that I didn’t want to delay it anymore. I am not an expert web developer by any means, so I can’t rule out my code as source of the problem, but I think the fact that my code works beautifully in Firefox yet has so many glitches in Internet Explorer is telling.

The first problem that I discovered was with the scroll bar for the text area where you enter messages. If the CSS width of the text area is defined as a percentage rather than a fixed value then the scroll bar is offset to the right by the amount of the border and padding of the containing element when text is entered. At first the scroll bar is drawn correctly, and if the text area is resized then the scroll bar is again correctly positioned until more text is entered. This effect occurs even when the scroll bar is not visible, instead offsetting the window background. The image below shows the problem, and I’ve also created a simple test case.

I was able to fix the problem using a unique feature of Internet Explorer — CSS expressions. I added the following code to the stylesheet:

textarea.messageFormBody {
	width: expression(this.parentNode.parentNode.parentNode.offsetWidth - 19);
}

All’s well that ends well? Not quite. First, you can see that I had to hardcode the offset. If the padding of any of the containing elements changes, this value will need to be updated. Worse yet, this code can crash Internet Explorer! If the offset is less than amount of padding between the containing elements and the text area, IE resizes the containing elements to fully contain the text area causing an infinite loop as IE then resizes the text area again, and so on. Finally, this code causes a slight glitch when opening a chat window for the first time as IE initially sizes the text area, which you can see in the image below. I decided this was a worthwhile tradeoff, but my Internet Explorer woes were just beginning…

Another annoyance was IE adding extra padding to the first group in an identity, and the first contact in a group. In the image below you can see that there is extra space between the name of the AIM Bots group and the first contact in the group, while the first contact in the Buddies group appears immediately below the name. Also, there is more space between the first contact in the AIM Bots group than there is between the second contact and the next pager node.

After creating another simple test case I determined that this was because I was defining the font properties in the block-level elements and letting the inline elements inherit rather than setting the properties directly on the inline elements. IE still adds two pixels of extra padding even after updating the stylesheet, but at least now it is uniform. In the next release I may take advantage of IE’s ability to use conditional stylesheets to remove the padding from these elements, instead relying on IE’s extra whitespace to provide the proper spacing (since IE clearly knows padding better than I do), but I’m not sure that I want to stoop to IE’s level by using such a hack.

While these glitches were mere annoyances, the next issue was a major problem. If IE’s Temporary Internet Files settings are set to “Every visit to the page” then IE will request background images from the server every time a dynamic action is taken on the page! This causes the images to flicker, but more importantly it creates a ton of extra requests to the server. What at first appeared to be an annoyance turned out to be a threat to my design principles! Although this is a browser issue, it can be fixed with some server-side tweaks. I have incorporated those settings into the Apache HTTP Server configuration snippet included in the distribution, but Apache HTTP Server is an optional package; the issue remains when serving Yafumato directly from Apache Tomcat. I have noted this issue in the release notes with instructions for ensuring that the IE is properly configured to avoid this problem. More information about this issue is available at http://www.fivesevensix.com/studies/ie6flicker/.

Next, IE doesn’t create horizontal scroll bars for my DHTML windows’ contents. Instead it resizes the div to hold the contents without side-scrolling and refuses to resize the element any smaller than that. The windowing code sets the minimum resize width to be the width of the window contents, but that is set when the window is created; dynamically added content can still be a problem. This is still an open issue.

Finally, there are glitches with the script.aculo.us combination effects. Adjacent elements are briefly offset when using effects such as “SlideUp” or “Squish” to hide an element. Also, when using an expanding effect to make a large element appear, the portions of the expanding element that are outside of a DHTML window are briefly visible; the element is only clipped when the effect completes.

TLV the 0×0013th

A little while ago I had a problem — I wasn’t receiving any messages on AIM. At least, I wasn’t receiving any messages from my friends; the moviefone and shoppingbuddy bots were working fine. At first I thought I was just a pariah, but I realized that I had a real problem when the problem continued on Monday the 13th. I turns out that DAIM was throwing exceptions while parsing the messages. The problem turned out to be TLV chain 0×0013:

/*
 * Possessed TLV type, type 0x0013.
 *
 * A TLV of type 0x0013 can only be 2 bytes, despite its
 * server-specified length. I have never seen this in action, but
 * having this here hasn't ever broken anything.
 */
if (type == TLVType.AIM_TLV_ATH_REGISTRATION_STATUS && length != 2) {
    len = 2;
}

Apparently this idiosyncrasy was fixed, as this TLV chain is now confirming to the server-specified length. Messages from the bots don’t have this TLV chain, so they worked. This made things easier to debug, as I was able to compare the DAIM hex dumps and identify the problem. I’ve patched daim.jar, and will be releasing this patch soon.

While debugging this issue, I contacted the developer of the DAIM API, David Walluck. I’m going to try to join the DAIM project as a developer since David is busy with grad school and looking for someone to take over the project.

This issue underscores an important point — neither API propagates exceptions up to the application. This is a flaw that is going to have to be fixed before Yafumato can move out of the alpha stage.