Problem with jQuery 1.7+ and SPServices

<UPDATE dateTime=”2012-12-04″>

This issue is resolved in v0.7.0+. See this post for more details, including the SPFilterNode function. </UPDATE>

<UPDATE dateTime=”2011-11-15T11:59GMT-1″>

Steve Workman has come up with a much improved way to do the selecting for things like z:row in general – it’s much faster, as Steve’s statistics show – and it also works with jQuery 1.7. I’ve added it to the latest alpha for v1.6.3 (which I will probably rename v0.7.0). More details to come, but this issue is going to be resolved in the upcoming release of SPServices.


Alert reader Dustin Meany pinged me yesterday with a brief email through this blog: — I think you should update the documentation for SPServices…

Ah, if the issue were only as small as his email. The ticket on the jQuery site talks about the fact that the notation that I’ve been recommending to parse through the results of a call to the Web Services, like:

$(xData.responseXML).find("[nodeName='z:row']").each(function() {
  // Do something

is no longer valid in jQuery 1.7.

I’ve confirmed in my main test pages that jQuery 1.7 no longer matches on any z:rows in calls to GetListItems. That breaks the majority of the “value added” functions in SPServices. The [nodeName='z:row'] notation has proved highly useful to ensure cross-browser compatibility, and that was the reason I’ve been recommending it in the first place. Because GetListItems uses the somewhat odd namespace of z:row, not all browsers react the same way. Of course GetListItems is the single most used Web Service operation with SPServices. Most of the other operations, which are used less often, do not use this type of namespace.

So the question is how we as a development community handle this. Based on the suggestion in the jQuery ticket, I could implement a function in SPServices itself that probably will solve the issues for the SPServices value-added functions. There are only ten calls in SPServices at the moment that use the [nodeName='z:row'] notation. However, there are thousands of you out there who have your own custom scripts written on top of SPServices that will break if you move to jQuery 1.7+.

The suggestion of switching to the .find("z\\:row, row") notation may work. I’ve quickly tested it with IE9, Chrome 15, Safari 5.1, and Firefox 7.0, all on my Windows 7 laptop. I don’t trust my cursory test, of course; there’s more work to do.

I hold no sway over the jQuery development team. They make their decisions without any knowledge of my little SPServices library or probably even SharePoint.

This, along with the XSL timeout issue I wrote about yesterday, may prove to be a big blow to those of us who choose to develop in SharePoint’s Middle Tier. As the standard bearer for this little movement, I can only do so much to make noise about how important and useful these development techniques are. When these types of roadblocks are put up, there’s little I can do to change things.

"Please Upgrade Your Browser to IE8 or Above": But I’m Already Running IE8!

This one is from way off in left field, but it explains many oddities that I’ve seen over the last 6 or more months, I think. Stick with me as I explain it. There are some goodies along the way, as well as the solution to this problem. At the very least, I get to gratuitously stick a bunch of cool images and logos into a pretty long post.

imageYesterday I saw a tweet from my good friends over at TripIt (if you travel, even only occasionally, you *must* try TripIt!) about all the cool sites that are now integrating with them. One imageof those, called Tripline, caught my eye. An article at TripIt’s blog called How Many Third Party Apps Have You Synced with TripIt? says:

Easily make sharable, animated trips with photos, music, links, and stories.  Once you connect your Tripline account with TripIt, you can import your TripIt trips into Tripline, which will automatically create a travel map for this trip, equipped with travel dates and places. It’s a great way to share your trips with friends, or relive them later.

To get started, create your free Tripline account, then connect your TripIt account on their settings page.

imageWimageell, yeah, that sounded awesome. So I signed up immediately using the browser on my iPhone from my couch. Of course, that experience left a little to be desired, so today I went to load up Tripline on my laptop, and the site told me that I had an unsupported browser and I should upgrade to IE8.

Now wait a cotton-pickin’ minute! I am running IE8!

imageCome to think of it, Microsoft’s sites have told me I should upgrade my browser for months, too, and way before IE9 was in beta. (See, this goes back a while.) Proud Microsoft supporter that I am, I assumed that they had a bug in their browser detection and kept ignoring it.

Well, this really annoyed me, so I turned to Twitter for help, and my pals Matt Bramer (@IOnline247) and Brian T Jackett (@BrianTJackett) suggested turning off add-ons and checking the Compatibility Mode, respectively. Nope and nope. However, since I had imageChrome installed and told me that I was running Chrome, which was claiming to be IE8 (this was a red herring), I uninstalled Chrome, imageGoogle Gears, and imageChrome Frame. Still no dice. At least was telling me at that point that I was running IE8, but on Windows XP!image I have been running imageWindows 7 since the beta, thank you very much! (FWIW, I like Chrome, but even though Matt keeps telling me to switch to it completely, my clients mainly use IE, and so I mainly use IE. Besides, I’ve used IE since imageversion 1.0. Why switch?)

Where the heck is this going, you might ask? Well, stay with me.

Since Tripline seemed really intriguing, and this whole “you’re running an old browser” thing was now truly pissing me off, I decided to email Tripline to see if they could tell me why they wanted to upgrade my already fairly fresh browser. Here, I probably owe the Tripline folks an apology, since I had an inkling that it wasn’t a problem on their end, but I really didn’t know.

Well, it was Byron at Tripline HQ to the rescue, I’ll tell you. Unlike many support experiences (don’t get me started), this one was A#1 top notch. I got an email back almost immediately, and Byron really wanted to figure this one out.

Byron suggested the Compatibility View angle (as we already know, that was a dead end), but in his next email, he asked me to check what my browser was reporting in its User Agent string by typing


into the address bar. (See this MSDN article for details on what this does.)image

Now we were getting somewhere. Here’s what I got:


imageByron saw what was going on right away (highlighted above). My browser was reporting that it was IE8 just fine, but it was also reporting that it was IE6! Byron pointed me to this article which, way down at the bottom, suggests what might be happening and how to fix it. (I’ve taken the liberty to copy that section of the article below. Thanks to Eric Lawrence and his EnhanceIE site.)

I found the offending User Agent string in the

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Post Platform

key and just for completeness, I searched the registry for other occurrences of “MSIE 6.0” and found the following:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows Search\Gathering Manager


I left that one alone, but interesting, eh?

So, I deleted the offending value in the

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Post Platform

key, rebooted, and wah-la: I’m running IE8 again!

Here’s my nice, clean User Agent string, and now I’m even running the 64 bit version of Windows 7 when I go to




Thanks again to Byron at Tripline. Check out their stuff. It looks totally awesome. Especially in IE8.


Solution from the Eric Lawrence at his EnhanceIE site

Problem: Nested UA String

In this case, the User-Agent string is corrupted, with two instances of the Mozilla/4.0 token. This typically is caused by a bad registry key. Problems of this nature are caused by poorly written addons or utilities that write incorrect values to the registry.

GET / HTTP/1.1
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 3.5.30729; InfoPath.2)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

As you can see in the example above, an IE6 user-agent string is written in the middle of the IE8 user-agent string. This bad string is dynamically generated out of a registry key. By removing the registry key, you can fix the problem.

To fix this, click START > RUN > REGEDIT.EXE. Using RegEdit, navigate to these four keys:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Post Platform
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Post Platform

…and remove any elements from the “Name/Type/Value” list that contain Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ;

For 64 bit computers, also check:

HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform