This project has moved and is read-only. For the latest updates, please go here.

Issue with SPArrangeChoices and Safari on Mac/iPad

Apr 20, 2012 at 5:39 PM

So I have SPArrangeChoices working *great* on IE8, Firefox and Chrome... however Safari and Mobile Safari refuse to work correctly and the radio buttons display vertically still. Bleh.

I'm running the latest version of mobile Safari and desktop (mac) Safari is version 5.1.5.

Here's the code for the field:

<td width="100%" valign="top" class="ms-formbody" colspan="2">
<h3><label>Thoughtful Work</label></h3>

<xsl:comment>FieldName="Thoughtful Work"</xsl:comment>
<SharePoint:FormField runat="server" id="ff6{$Pos}" ControlMode="New" FieldName="Appropriate_x0020_Scheduling" __designer:bind="{ddwrt:DataBind('i',concat('ff6',$Pos),'Value','ValueChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@Appropriate_x0020_Scheduling')}"/>


I'm referencing the following JS:

<script language="javascript" type="text/javascript" src="../../../jquery/jquery-1.7.2.min.js"></script>
<script language="javascript" type="text/javascript" src="../../../jquery/jquery.SPServices-0.7.1a.js"></script>

And here is my SPServices code (note that cascading drop downs does not work in Safari either):

$(document).ready(function() {
		relationshipList: "Teachers",
		relationshipListParentColumn: "School_x0020_Name",
		relationshipListChildColumn: "Title",
		parentColumn: "School",
		childColumn: "Teacher",
		simpleChild: true,
		promptText: "",
		selectSingleOption: true
	columnName: "Thoughtful Work",
	perRow: 4

I'm stymied! why is this not working correctly on the one browser (iPad) I need it to work in?

Thanks in advance for the help!

Apr 20, 2012 at 5:45 PM


I just went to my standard WSS test list and both functions seem to work fine in Safari. My guess is that the script files aren't being pulled in. Check to make sure that they are loaded; it's probably an auth issue.


Apr 20, 2012 at 6:32 PM
Edited Apr 20, 2012 at 6:38 PM

Edit: Used Firebug for Safari... the scripts are all loading. Thoughts?

Apr 20, 2012 at 6:39 PM

I'm not that familiar with the developer tool options in Safari. If it was IE I'd use the Developer Tools, if it were Firefox I'd use Firebug. Both of those tools allow me to look at what script files are loaded in the page.

Another trick would be to add an alert into the script and see if it fires.

Finally, you could switch to referencing the files on a CDN rather than locally to see if that works better.


Apr 20, 2012 at 7:22 PM

So it looks like it is an issue with utilizing SPCascadeDropdowns and SPArrangeChoices at the same time. When I no longer call CascadeDropdowns all the SPArrangeChoices functions fire just fine in Safari.

Apr 20, 2012 at 8:42 PM

The two functions should coexist just fine; they do in my test pages. Maybe you have a missing semicolon or something?


Apr 25, 2012 at 6:02 PM

So I gave up on using arrange choices and just did this as part of my $(document).ready(function):


Doing this twice removes the TD and TR tags generated by SP for each radio button and leaves them open to further formatting.

I still can't get the latest version of CascadeDropdowns to work on Safari. I noticed your demo site is still running an older version of SPServices (0.5.8) and JQuery (1.4.2), which seems to work fine in Safari. However, using the most recent version of JQuery (1.7.2) and SPServices (0.7.1a), I've noticed that Safari chokes when processing this line in fn.SPServices.SPCascadeDropdowns... it just won't go any farther through the script:

var childColumn = {opt: opt, childSelect: childSelect, childColumnStatic: childColumnStatic, childColumnRequired: childColumnRequired};

It works great in all other browsers except for Safari. Thoughts?

Apr 25, 2012 at 6:27 PM

I just opened my standard test site in Safari 5.1.5 and the cascading seems to work just fine. The page is using jQuery 1.72 and SPServices v0.7.2ALPHA2 (minor changes from v0.7.1 so far).

Can you debug to that line and see if any of the values are undefined or otherwise a problem?


Apr 25, 2012 at 7:01 PM
Edited Apr 25, 2012 at 7:01 PM

childColumnStatic and childColumnRequired are not getting set by the function. This section is not firing in Safari at all (listName and childColumn are valid variables), and I've confirmed in every other browser:


		// Get information about the childColumn from the current list
			operation: "GetList",
			async: false,
			listName: opt.listName,
			completefunc: function(xData, Status) {
				$(xData.responseXML).find("Fields").each(function() {
					$(this).find("Field[DisplayName='" + opt.childColumn + "']").each(function() {
						// Determine whether childColumn is Required
						childColumnRequired = ($(this).attr("Required") === "TRUE") ? true : false;
						childColumnStatic = $(this).attr("StaticName");
						// Stop looking; we're done
						return false;
Apr 25, 2012 at 7:20 PM

If childColumnStatic and childColumnRequired are not getting set, it would imply that the call to GetList immediately prior must be failing. Can you tell what's coming back from that call?


Apr 25, 2012 at 7:35 PM
Edited Apr 25, 2012 at 7:35 PM

The call manages to process up till this:

completefunc: function(xData, Status) {

At which point, in Safari, Staus returns as "error". In every other browser, status is "success".

This is the point at which the call actually fails:

$(xData.responseXML).find("Fields").each(function() {
Apr 25, 2012 at 7:51 PM

Ok, I've tracked it down. listName is not getting set because of a failure in SPListNameFromUrl. There's a check in this call to see if the listPath.indexOf(listCollList) >0. This isn't happening in Safari (but it works in other browsers... weird!), so the call never sets the listName variable.

		// Call GetListCollection and loop through the results to find a match with the list's URL to get the list's GUID (ID)
			operation: "GetListCollection",
			async: false,
			completefunc: function(xData, Status) {
				$(xData.responseXML).find("List").each(function() {
					var defaultViewUrl = $(this).attr("DefaultViewUrl");
					var listCollList = defaultViewUrl.substring(0, defaultViewUrl.lastIndexOf(SLASH) + 1).toUpperCase();
					if(listPath.indexOf(listCollList) > 0) {
						thisList = $(this).attr("ID");
						return false;

Apr 25, 2012 at 7:58 PM

I *think* I see what's actually happening. It's actually related to a domain alias network issue. SPServices thinks my site is at the root of the SharePoint site collection (even though it isn't), so it's never returning the appropriate site URL and the script fails. If I VPN in via Safari, the code works.

Thanks for the triaging :)

Apr 25, 2012 at 8:14 PM

So do you see it as an issue with site topology on your end, or is SPServices blowing it somehow?


Apr 25, 2012 at 8:41 PM
Edited Apr 25, 2012 at 8:46 PM

Hard to say at this point. Site topology is pretty simple on this end. SPServices appears to be doing something weird, but I haven't dug into it too much.

As long as I specify lists by their GUIDs it works fine. Any other kind of reference (say by list name) starts causing the aforementioned crazy behavior.

Apr 25, 2012 at 8:49 PM
Edited Apr 25, 2012 at 8:49 PM

That's odd. Is your form in the list context, e.g., http://servername/sitename/lists/listname/thisform.aspx?


Apr 25, 2012 at 8:50 PM

Yup. http://fieldservice/icletemplate/Lists/School%20Visits/NewForm.aspx

May 3, 2012 at 4:08 AM

Did you figure this out?