Closed
Bug 463889
Opened 17 years ago
Closed 16 years ago
Can't add web parts in Sharepoint 3 and MOSS 2007
Categories
(Firefox :: General, defect)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: denli, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b2pre) Gecko/20081108 Minefield/3.1b2pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b2pre) Gecko/20081108 Minefield/3.1b2pre
When editing a page in a MS Sharepoint 3 site the selected web parts to be added isn't.
This worked in Firefox 2.x.
Reproducible: Always
Steps to Reproduce:
1. Go to a Sharepoint 3 site.
2. Log on with an account that has the right to edit the site
3. Click on drop down menu 'Site Actions' and select 'Edit Page'
4. Click on any of the available 'Add a Web Part' bars.
5. Add a web part of your liking and click on 'Add'
Actual Results:
The new web part isn't added to the page.
Expected Results:
The web part should be added to the page.
Comment 3•17 years ago
|
||
You reported this on Firefox/3.0.3 (mac & windows) and on Minefield/3.1b2pre. There's no need to report it 3 times. I duped them all to this one, but I left it on the 3.0 branch (even though this report is for 3.1)
OS: Mac OS X → All
Hardware: Macintosh → All
Comment 4•17 years ago
|
||
In fact, all modal windows are broken i Firefox 3. Identical symptoms can be observed when for example using the people picking (using the search dialog).
Somehow the callback that is supposed to occur after the window is closed, never occur.
Notably, Safari 3 is broken in the exact same way. Maybe SharePoint - hold on to something - doesn't follow appropriate standards in this case? Did they use a bug in Firefox 2 to make it work there? At least they didn't ignore other browsers completely, this specific JavaScript function for opening modal windows contain a substantial amount of code for working in other browsers.
If necessary, I can send copies of the broken SharePoint JavaScripts: commonShowModalDialog() and others in core.js and non_ie.js
If you could provide me with reference to the exact code I could open a case with Microsoft.
Comment 6•17 years ago
|
||
The primary source of the problem seems to be in commonShowModalDialog() in "/_layouts/1033/core.js". I have investigated three of the broken modal windows, all three of them use this function to display the window. It's also the smallest common denominator for the three broken windows.
---
I must revise my previous statement "Somehow the callback that is supposed to occur after the window is closed, never occur.". The callback occurs, but it seems the return value is invalid. Here is an example:
1. Go to Central Administration
2. Go to Application Management
3. Go to Create Site Collection ("http://host:port/_admin/createsite.aspx")
4. There should be a box showing one of the existing web applications. Click it and a small popup menu appears, showing only "Change Web Application".
5. Open it. A modal window appears, listing all available web application. "commonShowModalDialog() is used to display this window.
6. Click on one of the available web applications.
7. The modal window is closed and the page is reloaded.
Now, on IE7, this URL is opened:
http://basemossdev:5000/_admin/createsite.aspx?WebApplicationId=4d945a85-bcea-4317-b5ac-7d58b0ade74e
Which is correct.
On FF3, this URL is opened:
http://basemossdev:5000/_admin/createsite.aspx?WebApplicationId=null
Which is incorrect. The box that contained a web application now shows "No selection", independant of the choice just made.
---
Here is a code of the commonShowModalDialog() function in "core.js":
function commonShowModalDialog(url, features, callback, args)
{
if (document.getElementById("__spPickerHasReturnValue") !=null)
document.getElementById("__spPickerHasReturnValue").value="";
if (document.getElementById("__spPickerReturnValueHolder") !=null)
document.getElementById("__spPickerReturnValueHolder").value="";
var rv;
if (window.showModalDialog)
{
rv=window.showModalDialog(url, args, features);
if(callback)
callback(rv);
}
else
{
var defaultWidth=500, defaultHeight=550, defaultScrollbars="yes";
if(!features) features="width="+defaultWidth+",height="+defaultHeight;
else
{
function assocArray() { return new Array(); }
function assocArray_add(array, key, value)
{
array.push(key);
array[key]=value;
}
function assocArray_keys(array)
{
var keys=new Array();
for(var i=0; i<array.length; i++) keys.push(array[i]);
return keys;
}
var feats=assocArray(), fre, split;
if(features.search(/^(\s*\w+\s*:\s*.+?\s*)(;\s*\s*\w+\s*:\s*.+?\s*)*(;\s*)?$/) !=-1)
{
fre=/^\s*(\w+)\s*:\s*(.+?)\s*$/;
split=features.split(/\s*;\s*/);
}
else
{
fre=/^\s*(\w+)\s*=\s*(.+?)\s*$/;
split=features.split(/\s*,\s*/);
}
for(var feat in split)
{
var kv=fre.exec(split[feat]);
if(kv && kv.length==3) assocArray_add(feats, kv[1].toLowerCase(), kv[2]);
}
if(!feats["width"]) assocArray_add(feats, "width", feats["dialogwidth"] || defaultWidth);
if(!feats["height"]) assocArray_add(feats, "height", feats["dialogheight"] || defaultHeight);
if(!feats["scrollbars"]) assocArray_add(feats, "scrollbars", feats["scroll"] || defaultScrollbars);
features='';
var keys=assocArray_keys(feats);
for(var i in keys)
{
if(features) features+=",";
features+=keys[i]+"="+feats[keys[i]];
}
}
var modalDialog=window.open(url, '_blank', features+',modal=yes,dialog=yes');
modalDialog.dialogArguments=args;
window.onfocus=function() {
var bHasReturnValue
=((document.getElementById("__spPickerHasReturnValue") !=null) &&
(document.getElementById("__spPickerHasReturnValue").value=="1"))
|| commonModalDialogReturnValue.isSet();
if (modalDialog && !modalDialog.closed && !bHasReturnValue)
{
modalDialog.focus();
}
else
{
window.onfocus=null;
if(callback)
{
if (typeof(modalDialog.returnValue) !="undefined")
{
rv=modalDialog.returnValue;
callback(rv);
}
else if (commonModalDialogReturnValue.isSet())
{
rv=commonModalDialogReturnValue.get();
callback(rv);
commonModalDialogReturnValue.clear();
}
else if (document.getElementById("__spPickerHasReturnValue") !=null &&
document.getElementById("__spPickerHasReturnValue").value=="1" &&
document.getElementById("__spPickerReturnValueHolder") !=null)
{
rv=document.getElementById("__spPickerReturnValueHolder").value;
callback(rv);
}
}
}
}
}
}
Comment 7•17 years ago
|
||
Sorry, here are more code used by commonShowModalDialog(), also in core.js, I'm guessing this code also might be important? If you need more references or code I'll be happy to supply it.
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;
}
else
{
setModalDialogObjectReturnValue(wnd, returnValue);
}
}
function setModalDialogObjectReturnValue(wnd, returnValue)
{
if(wnd.opener !=null)
{
wnd.opener.commonModalDialogReturnValue.set(returnValue);
}
else
{
wnd.returnValue=returnValue;
}
}
commonModalDialogReturnValue={
hasRetval: false,
retVal: null,
set: function (obj) {
if(typeof(obj) !="undefined")
{
this.retVal=obj;
this.hasRetval=true;
}
},
isSet: function() { return this.hasRetval;},
get: function() { if(this.hasRetval) return this.retVal; },
clear: function() { this.hasRetval=false; this.retVal=null; }
}
Comment 8•17 years ago
|
||
I have found more specifically where the issue is.
It is in the function setModalDialogReturnValue(), more specifically the first test:
if (wnd.opener !=null &&
typeof(returnValue)=='string' &&
wnd.opener.document.getElementById('__spPickerHasReturnValue') !=null &&
wnd.opener.document.getElementById('__spPickerReturnValueHolder') != null) {
For IE7, the getElementById's evaluate to null, so the "if" clause evaluates to false.
For FF3, they evaluates to a HTMLInput object, so the "if" clause is true.
I don't know if the problem is on Firefox' or SharePoint's side, but the problem can be worked around by adding this line:
wnd.returnValue=returnValue;
on an appropriate place in setModalDialogReturnValue() and/or setModalDialogObjectReturnValue(), or preferably, to change the If clauses. (Changing the If clauses is the way to go if it should still work in older browsers without JavaScript errors.
Note that changes in core.js are not encouraged - the file may be replaced by future service packs, etc.
Comment 9•17 years ago
|
||
I should note that the fix above is very "quick and dirty". While it works in IE7, FF3 and Safari 3, it will probably break stuff in older browsers.
While it's possible to work around the problem, and it should be fairly easy to make the fix available as a custom SharePoint solution, I recommend anyone being troubled by this issue to open a support case with Microsoft.
Comment 10•16 years ago
|
||
thanks for digging into this.
But before I open a support case at MS, can we be sure that it is nothing in FF3 that breaks SharePoints modal windows? I ask because - as mentioned in the first post - all those picker windows do work when using Firefox 2
Comment 11•16 years ago
|
||
I will try to explain why it works in Firefox 2.
Different methods are used depending on browser, to do the following when opening a modal window:
1. In parent window - open a modal child window:
a) Using window.showModalDialog()
b) Using window.open()
2. In child window - save the return value:
a) Set window.returnvalue variable
b) Set a specific hidden form <input> field value in the parent window
3. In parent window - get the return value:
a) Get window.returnvalue variable
b) Get the hidden form <input> field value
In FF2, SharePoint chose "b" in all cases, in IE it chose "a" in all cases.
In FF3, the showModalDialog has been implemented. This causes "1a" and "3a" to be used, BUT it still use "2b" to save the value.
In short: SharePoint's browser detection code for these methods needs to be updated, and that's pretty much it...
Reporter | ||
Comment 12•16 years ago
|
||
I've opened a support case with MS.
Reporter | ||
Comment 13•16 years ago
|
||
I used the wrong support contract.
I've opened a new case today with a valid support contract.
Reporter | ||
Comment 14•16 years ago
|
||
I've been talking with MS now and the thing is that MOSS was designed for the way Firefox v2 worked (obviously).
So MS can't classify this issue as a bug in MOSS per see as the working in Firefox was changed.
They would like, however, to get feedback and requests from the community for future versions of MOSS/WSS.
If you (like me) would like MOSS/WSS to support Firefox please register an account and vote for the Feedback at https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=434004&SiteID=428
The more that vote the bigger the chance that MS will take notice and prioritize this issue.
Comment 15•16 years ago
|
||
Unfortunatelly that link does not work for me. Can you provide an alternative one?
"as the working in Firefox was changed."
-- amazing, concidering that the only relevant "change" is that new JavaScript methods are supported.
I guess the community has no other choice but to fix the bug themselves, which is located in the 450 kb "core.js", where changes are not supported. Terrific.
Reporter | ||
Comment 16•16 years ago
|
||
The link above is reverified and do work.
Please vote for this issue.
Comment 17•16 years ago
|
||
Nope, you seem to have different status at microsoft.com than everybody else. I still get only an error
<q>
Page Not Found
The content that you requested cannot be found or you do not have permission to view it.
If you believe you have reached this page in error, click the Help link at the top of the page to report the issue and include this ID in your e-mail: 72ea3f77-0615-4c4e-b25a-21b8d9de6ee6
</q>
Reporter | ||
Comment 18•16 years ago
|
||
Very strange.
Maybe you need to register an account at http://connect.microsoft.com first?
Comment 19•16 years ago
|
||
ah, ok. I was logged in with my liveID but apparently this was not enough. Had to register to this connect thing too.
Reporter | ||
Comment 20•16 years ago
|
||
Microsoft has released SP2 for WSS 3.0 and SP2 for MOSS 2007.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 21•16 years ago
|
||
I am glad your issue has been resolved, but that makes this bug WORKSFORME. FIXED is only for a bug that has had a known patch checked into the tree, which has not happened in this case.
Status: RESOLVED → VERIFIED
Resolution: FIXED → WORKSFORME
Reporter | ||
Comment 22•16 years ago
|
||
Ahh :-)
Well then. It works for me if I apply SP2 for Sharepoint.
You need to log in
before you can comment on or make changes to this bug.
Description
•