Visar inlägg med etikett Safari. Visa alla inlägg
Visar inlägg med etikett Safari. Visa alla inlägg

onsdag 3 december 2008

Firefox, Safari, SharePoint and modal windows

Ok, I've been taking a closer look at the problem with SharePoint, modal windows, Firefox and Safari.

Turns out the problem is NOT Firefox/Safari, rather, it is an issue with the setModalDialogObjectReturnValue() function in core.js. Basically, because of differences between Firefox/Safari and Internet Explorer, the result of the 'if' clause in this method is different. For Firefox/Safari, this has the result that the wrong method is used to set the return value of the window.

Here is a very quick and dirty workaround that works in FF3, Safari 3 and IE7 (and WSS 3.0 SP1/MOSS 2007 SP1).

Add the bold line to ...\12\TEMPLATE\LAYOUTS\1033\CORE.JS:

function setModalDialogReturnValue(wnd, returnValue)
{
  if (wnd.opener !=null &&
    typeof(returnValue)=='string' &&
    wnd.opener.document.getElementById('__spPickerHasReturnValue') !=null &&
    wnd.opener.document.getElementById('__spPickerReturnValueHolder') !=null)
  {
    wnd.opener.document.getElementById('__spPickerHasReturnValue').value='1';
    wnd.opener.document.getElementById('__spPickerReturnValueHolder').value=returnValue;
    wnd.returnValue=returnValue;
  }
  else
  {
    setModalDialogObjectReturnValue(wnd, returnValue);
  }
}

I put this here only to illustrate the problem and the solution. I have not tested this with older browsers - this code will probably break functionality with older browsers! Preferably, one should modify the 'if' clauses in this method. Also, mind that changes to this file is not supported by Microsoft. It might be overwritten by future Service Packs or upgrades, so you better hope that this bug is fixed in the next Service Pack, or somehow put this fix in some other file.


So who is to blaim? Who should fix it?

What Mozilla changed to make this problem arise in Firefox 3 was simply to add support for the IE specific method showModalDialog(). They didn't have to - they already had another way to do the exact same thing.

For Firefox 3/Safari 3, the JavaScripts in core.js now choose the "IE" method to open the window, the "Firefox" method to set the return value to the window, and then again the "IE" method to read the return value from the window. Hence, the return value will always be undefined or null. The JavaScript functions must be modified in some way so that they are concistent.

No one is to "blaim" - Firefox and Safari supports everything IE supports, and Microsoft made an effort to support Firefox in SharePoint, but even though SharePoint worked in all browsers available during its release, it now fails to properly detect modern browsers.

While it's possible to work around the problem, and it should be quite easy to make the fix as a custom SharePoint solution, I recommend anyone being troubled by this issue to open a support case with Microsoft.

tisdag 2 december 2008

Firefox vs SharePoint

One annoying thing when accessing SharePoint sites with Firefox is that it always requires the user to enter credentials when using NTLM authentication. It turns out, that's not a limitation, that is by design... Read this post by Patrick Cauldwell about how to make Firefox log in automatically to SharePoint sites.


Also, there's an issue in Firefox (and Safari) which disables most things which depend on popup windows, most notably, it's not possible to add web parts to a page.

Taking a look at the core.jss file, it appears that Microsoft put a fair bit of work into making this work in more than just IE, so it actually might be a bug in Firefox, not just Microsoft ignoring FF as I first thought. How about putting a vote for Bugzilla@Mozilla - Bug 463889 - Can't add web parts in Sharepoint 3 and MOSS 2007?