v2013.02ALPLA3 using Array.isArray() which is incompatible with Older IE browsers

Oct 18, 2013 at 10:00 PM

In running the latest version of SPServices in my development environment I have found an issue that makes it incompatible with older version of Internet Explorer... In the function_addToPlayload()_ (line 4084) you are using Array.isArray(), which is not available in older versions of IE..

I was using IE9, where this method of the Array object is supported (here), but was on SP2007 where the page was rendered in Quirks mode, so it failed.

Oct 18, 2013 at 10:05 PM
I should have mentioned this... Since SPServices is a jQuery plugin, you probably want to use $.isArray() to check if value is an array...
Oct 19, 2013 at 12:50 AM
Good catch. I was about to do it to everyone again! Regression testing!

Oct 19, 2013 at 1:20 AM
Glad I can help.
I have my code under source control, so maybe this weekend I'll do a Diff between v2010.01 and the latest and see if anything else stands out (call it code review).


Paul T

Oct 19, 2013 at 6:20 PM
I did a quick diff between 0.7.2 and 2013.02ALPHA3... Aside from the Issue you have open around caching, I have the following observations:

Looks like you introduced this in one of the newer versions of SPServices to take advantage of the _spPageContextInfo variable that Sharepoint >=2010 sets on the page... You are currently (at line 67) initiating this object as soon as SPServices loads which may not be optimal... It may be best for you to initiate it when one of the SPServices methods/utilities are first called, because that variable in some cases may not be initiated yet... (Full disclosure: I did not try to create this condition... its purely based on what I see).

When I search a SP page for the spPageContextInfo variable, it looks like it is initiated in the <body> of the document by code inserted in the server side. If SPServices was to be included/referenced in the <head> of the document, that variable may not yet be available.

$.fn.SPServices.SPGetCurrentSite and use of SPServicesContext.thisSite
Several users have reported issues with webURL being set incorrectly when left blank on input to SPServices... your more recent change (at line 430-431) might have fixed this for SPServices(), but you do call $().SPGetCurrentSite() in several other places, so not sure if this problem will arise again (I see it possibly in $.fn.SPServices.SPGetCurrentUser... see below).

SPServices seems to depend on the webURL value ending with a "/"... Here is a suggestion - In your SPServicesContextGet constructor, add code the following code after you have attempted to set thisSite variable:
        if (this.thisSite.length === "/") {
           this.thisSite = document.location.protocol + "//" + document.location.host + "/";
This would ensure that if the webURL is "/" then you actually use the base URL of the document.

If you decide to not take the approach above suggested for _SPServicesContextGet, then it looks like this utility ($.fn.SPServices.SPGetCurrentUser) has the same issue when attempting to use it form the Root site (url will be something like: http :///_layouts/userdisp.aspx?Force=True).

Hope this helps...

Oct 21, 2013 at 2:14 PM

I should have you review all my code. Every point here is valid. I'll work this stuff into the next alpha for your approval. ;+)

Nov 15, 2013 at 10:14 PM
Hi Marc...
I don't not know if you had accounted for this issue already (the use of Array.isArray)... I'm using 2013.02 ALPHA 3 and it still has the problem (just got bit by it :) )... I did not see you convert this to an Issue, so I'm hopping that your source already has the fix...

Nov 15, 2013 at 10:44 PM
In my current working alpha I have this:
            } else if(($.isArray(paramArray[i])) && (paramArray[i].sendNull !== undefined)) {

Nov 15, 2013 at 10:45 PM
p.s. I didn't convert this post to an issue(s), but it's on my mental list.

Nov 15, 2013 at 10:53 PM
Thanks Marc...
That's the change I made as well my local copy and its working in IE.

Paul T