Browser Inconsistencies: Part 2

Hey-o

Today was my first day at my new job. Exciting, but nothing notable yet. Hence, this is a relatively shorter entry.

Anyways, I was playing around with HTML and CSS again, putting together a chess/checkers-style board with HTML and CSS, and found another browser inconsistency.

I have a 4x4 grid of alternating white and black tiles. The tiles are arranged in rows, and there are tokens that are placed absolutely on top of them. The rows of tiles and tokens are all in a master div. The rows are each divs that have a clear: both property to make them cascade properly. At first, I didn't define the horizontal position of the tokens. In firefox/opera/chrome, you see the following:
















The absolutely positioned tokens are removed from where they "should" be, and are placed in the upper-left corner of their containing div (the white token has been defined to be that low). However, in IE8, this happens:















Apparently, if a horizontal position is not specified, the absolutely positioned elements stay where they would, even though they are removed from the box model. You can tell they have still been removed, because if they hadn't, then the border would be surrounding them as well. Setting the left: 0px; property makes IE8 render the same as all the others, but it is still interesting.

Browser Inconsistencies: Part 1

I did a freelance gig recently that required me to do some HTML/CSS. Like all web tasks, one of the primary concerns was browser compatibility. After several hours of cursing at IE and Firefox, I found a good php script that reliably detected browser, so I used that, but doing that always feels like cheating, so I'm going to be spending some time in the coming months playing around with CSS and HTML, looking at where the breakdowns occur. Here's my first post on the subject.

Surprisingly, when just messing around, it took a little while before I found my first break. I put two divs, one absolutely positioned, one relatively positioned, inside a larger div. The larger div was placed relatively at the top of the screen, and given the style "top: 20%;" What happened then? I'll show you.


















Surprisingly, Firefox was the one that did not register this style correctly. I'm pretty sure it is an issue, and not something laid down by the W3C. This is because when I changed the style to read "top: 20px;", both browsers behaved the same. Interesting.

OpenSocial Browser Incompatability

NOTE: This code and post was written for an older version of Opensocial. I make no guarantees as to it's validity in later versions.

Just a quick note: I'm going to set a goal for myself to do at least one blog post per week. It will be of a decent length, and not filler in any way, shape, or form. One of my biggest dislikes of the blogosphere is that people post the most useless stuff. I'm going to do my best to avoid it, but if I start sliding, someone let me know, please.


Back to the topic at hand...


I've been working with Google's new OpenSocial Framework recently (more info), which is a social networking framework that can be impelemented by social networking sites to provide cross-platform support for developers, making things a lot easier for third-party social app developers. There's one big glitch, though. It doesn't work on all browsers. I did some initial research on the topic, and was asked by Google to open a group dedicated to finding and documenting these differences (look here). The basic jist is this: Firefox and Opera work fine, IE and Safari don't. Safari asks for access to something in google's domain (which users/developers don't have access too,) and IE has something going on with it's requests.


In all the attempts that I made, any data request made from IE came back with a 401 Unauthorized Error. So I looked at the request made (using Fiddler, which is a great piece of software). So here's what I found in a request for the information about the viewer of a page.


IE Request:

POST /46/o/api/json HTTP/1.1
Accept: */*
Accept-Language: en-us
Referer: http://64b409ht-a.gmodules.com/ig/ifr?url=http://www.cs.drexel.edu/~asc38/Google/Test6.xml&parent=http://sandbox.orkut.com&lang=en-US&country=US&synd=orkut&mode=canvas&nocache=2147483647&mid=0&h=200#st=AFinprSFNk0cx-EYLjFu4KnGC8ErtahjWjnpbuHHWFEYTpx2pp2zBPW-N1gC-xtto2aB3gq7RW_B4wcDS1GzSkXNRoJrD0ScvjxAEhcmWl0_LvGe1TyJDm0&gadgetId=06080089800194424967&gadgetViewer=09795457263253596479&gadgetOwner=09795457263253596479&nocache=2147483647
Content-Type: application/x-www-form-urlencoded;charset=utf-8
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.5.20706; .NET CLR 3.0.590)
Host: 64b409ht-a.gmodules.com
Content-Length: 190
Proxy-Connection: Keep-Alive
Pragma: no-cache
req=%5B%7B%22key%22%3A%22viewer%22%2C%22request%22%3A%7B%22type%22%3A%22FETCH_PERSON%22%2C%22parameters%22%3A%7B%22id%22%3A%22VIEWER%22%2C%22profileDetail%22%3A%22basic%22%7D%7D%7D%5D&out=js


Looks pretty standard, huh? The body has a value named req, which appears to have some of the request data. There's also a decent bit in the referrer header as well. For some reason, however, this gets the 401 error. Let's check out the Firefox request, and see what the difference might be.


Firefox Request:
POST /46/o/api/json HTTP/1.1
Host: 64b409ht-a.gmodules.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Content-Type: application/x-www-form-urlencoded;charset=utf-8
Referer: http://64b409ht-a.gmodules.com/ig/ifr?url=http://www.cs.drexel.edu/~asc38/Google/Test6.xml&parent=http://sandbox.orkut.com&lang=en-US&country=US&synd=orkut&mode=canvas&nocache=2147483647&mid=0&h=200
Content-Length: 313
Pragma: no-cache
Cache-Control: no-cache
req=%5B%7B%22key%22%3A%22viewer%22%2C%22request%22%3A%7B%22type%22%3A%22FETCH_PERSON%22%2C%22parameters%22%3A%7B%22id%22%3A%22VIEWER%22%2C%22profileDetail%22%3A%22basic%22%7D%7D%7D%5D&st=AFinprR418rXG6TALrKsP6Ad_U1xE3E7z2_F22lrqaGoNvFN2NpWE7zB6-nqW69Zy9W-sgP8QNvSu7aTXe_ZfeSe-vBNjAvJa_BUohr6C3_l89naEvApO9s&out=js


Notice a difference? The Firefox has a lot more detail in the req value, and a bit less in the Referer. Here's a little summary of what's in where.


As far as the referers go, both browsers have the same address, url, parent, lang, country, synd, mode, nocache, and mid parameters. In fact, after mid, the firefox referer value stops. IE just keeps going, with a "#" seperator, instead of a "&". Usually, "#"s are used as an anchor to a link on the page, but that doesn't make sense on two accounts. First, this is a referer to a page, and second, because the anchor apparently has a value too. Other than the "#" sign, it appears to be assigning some sort of key value to the variable "st". Then, it even goes on to declare the value of gadgetId, gadgetViewer, gadgetOwner, and another nocache.


The req value is also a very similar story. IE and Firefox have an identical value, except that IE doesn't include the st parameter, which Firefox does. The st values are different, but I'm guessing that st stands for "state", which one would expect to change. Would the state cause a 401 error? Maybe, only Google knows.


One other interesting thing to note. In the accept header, IE just has "*/*" listed, which I assume means that it accepts all formats. That's nice, but Firefox has the following listed in the accept header "text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, text/plain;q=0.8, image/png" (spaces added after commas by me).


I don't have any solid answers, but here's my hypothesis: the "anchor" value in the referer header of the IE request is what's doing it in. Somehow, that adds something to the request that is a no-go for OpenSocial, causing it to error out.