Why, Blog, Why?

A co-worker of mine just got back from the Webmaster Jam Session and relayed this metaphor for Sharepoint, Microsoft's CMS/Portal/EBTKS-ware, which we have been evaluating:

Implementing Sharepoint is a lot like building a house. It's like a friend of yours says, 'I know exactly what to do.' And, he drives you to a Home Depot, drops you off at the front door and says, 'Everything you need is here.'

Paraphrased from Jared Spool

Since I just spent the better part of Friday debugging this problem and then the better part of Friday night Googling for a work around, it's worth noting that there is a "bug" in the Firefox implimentation of the xmlHTTPRequest object when using it for synchronous calls (i.e. the rest of the script pauses and waits for the request to complete, unlike typical asynchronous AJAX calls). When using the xmlhttp object in a synchronous fashion, Firefox does not process the onreadystatechange handler. Thus, any libraries that are dependant on this (for running post processing functions for example) will fail to work under these conditions. Interestingly, having the Firebug extension installed causes the object to behave properly. So a secondary note is to always test your apps in a "clean" instance of Firefox.

Here are the details that I came across, along with a work around: Lukav’s Weblog » Blog Archive » Firefox firebug and synchronos calls problem.

I've also set up a set of tests to demonstrate the problem. Try in both Firefox and IE to see the differences.

Originally posted to microsoft.public.outlook.calendaring Usenet group, April 10th, 2007

I just spend about 4-hours between yesterday afternoon and this morning trying to import an iCal file into Outlook 2003. No errors occurred during the numerous importing attempts, but afterwards the events did not appear on the days that they should have. Yet the number of unread/upcoming events next to the calendar name increased every time I tried to import.

I tried searching for the missing items using the Advanced Find dialog, but they would never appear in the results. I even tried exporting the whole calendar as an Excel file using a very wide date range (all events from 1970 through 2038), but the events were not listed in the export either.

Finally, I tried applying the predefined "By Category" filter to the standard Calendar view (available in the Advanced toolbar group). There were all of my phantom events - they included no information whatsoever and were in fact listed as email items rather than calendar items. I was able to delete them from that view and return my item count back to normal.

Now I just had to get around the importing problem. After searching various resources for an explanation, the best that I could come up with is that Outlook doesn't like some Timezone data that tends to get included in iCal files that originate from a Mac client. No other information was included on what in particular Outlook didn't like or if there was a direct work around, so I did some experimentation on my own. The solution is actually easier then you might expect. First, I imported the offending iCal file into a new Google calendar. Then, I downloaded Google's rendition of the file from the Private iCal link under the Manage Calendars panel. Finally, I imported this new iCal file into Outlook using the normal Import/Export dialog. Now the events appear as expected.

If you're interested in trying to this all yourself, you can find the original iCal file at http://www.web2expo.com/webex2007/schedule/ - Import the file as-is into Outlook, then apply the "By Category" filter to see where they went to.

I was burned by the document.getElementById() may return incorrect element in IE and Opera bug again today. This time though it was particularly bothersome as I spent the better part of the afternoon trying to figure out why I couldn't access the length property of the value of a textarea element in IE when the same code worked fine in Firefox. I mean, getting the length of a value of any form element through JavaScript usually isn't like rocket science.

<textarea id="description" name="description">Here is some text</textarea> <script type="text/javascript"> var myElement = document.getElementById('description'); alert(myElement.value.length); //alert: 17 </script>

Every time I tried to execute that code in IE it would complain that 'value.length' is null or not an object. After a whole crap load of debugging I finally tracked it down to the fact that IE was actually referencing the <meta name="description"> tag in the head section of the page. Yeah, see even though the function is getElementById, IE still thought I meant the element with the name attribute equal to "description". Or as my brother put it in a comment to the original post (before the comments were wiped in the great Data Loss of '06), maybe IE thought I was calling the getJustAboutAnythingIFeelLike() function... Damn you IE for making me have to change my ID attributes to suite your leisurely implementation of the DOM!

I came across a bug in Internet Explorer whereby the document.getElementById() function may return an element with a name attribute equal to the id that is specified. This can cause unexpected results.

According to the W3C’s DOM Level 2 Core Specification:

getElementById introduced in DOM Level 2

Returns the Element whose ID is given by elementId. If no such element exists, returns null. Behavior is not defined if more than one element has this ID.

Note: The DOM implementation must have information that says which attributes are of type ID. Attributes with the name “ID” are not of type ID unless so defined. Implementations that do not know whether attributes are of type ID or not are expected to return null.

Parameters

elementId of type DOMString

The unique id value for an element.

Return Value

Element

The matching element.

No Exceptions

http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-getElBId

However, for the browsers that failed the test, it appears that their implimentation of getElementById returns the first element where the ID or name attribute is equal to the specified ID.

This bug was tested against the following browsers:

• IE 6.0 sp2: failed
• IE 5.5: failed
• IE 5.01: failed
• Netscape 7.2: passed
• Netscape 6: passed
• Mozilla 1.7.3: passed
• Opera 8.2: failed
• Firefox 1.0.6: passed

For instance, the following code should produce an alert with “foo=foo; bar=bar”. However, the browsers that fail the test actually return “foo=foo; bar=foo”.

<form name="form1" id="form1" method="get" action="javascript: void(0)">
<input name="bar" type="text" id="foo" value="foo" /><br />
<input name="foo" type="text" id="bar" value="bar" readonly="readonly" /><br />
<input type="button" name="Button" value="Test" onclick="alert(’foo=’+document.getElementById(’foo’).value+’; bar=’+document.getElementById(’bar’).value)" /><br />
</form>

Test Page

Reported at http://www.quirksmode.org/bugreports/ (permalink)

Noted on http://channel9.msdn.com/wiki/ (Update 2007-04-04: my note has since been replaced by several others