Update Rollup 7 (CRM2011) causes javascript errors on forms opened from report links? RRS feed

  • Question

  • Can anyone duplicate/confirm the following behavior with Update Rollup 7?

    1. Open an out-of-box (or custom) report in CRM that has hyperlinks to some CRM object other than the 'user' object (accounts, contacts, etc)

    2. Click a hyperlink in the report.

    3. CLOSE the form that was opened from the hyperlink - get a 'Microsoft Dynamics CRM has encountered an error' popup with the following content.

    <Message>Object doesn't support this property or method</Message><Line>351</Line>

    And then in developer tools (F12) line 351 appears to be in the SETFORMMODE() function.

    351: masterWindow().setFormMode(2,'Edit');

    It seems like this 'masterWindow' may not be getting initialized properly when hyperlinked from a report window. If I copy/paste the same hyperlinked URL into a new tab in IE, it loads correctly and does NOT display this error when I close the form.

    Monday, April 2, 2012 3:57 PM

All replies

  • This appears to be a confirmed regression in UR7, case pending with Support.
    Tuesday, April 3, 2012 4:04 PM
  • Hi,

    we have the same problem.

    On rollup6 it worked, using IE9.

    On rollup7, only using IE8. The problem is that our customer is using IE9.

    Do you know if a hot fix is available ? For us it is urgent to have a fix.

    Tuesday, April 10, 2012 2:31 PM
  • Hi All,

    I have the same issue.

    This issue arises after update rollups have been installed. To prevent these errors, Microsoft suggests always clearing the IE cache after installing an update rollup.

    Steps to clear cache in IE,

    Open IE->Tools->Internet Options->General tab-> Under browsing history click Delete.

    Check Temporary Internet Files, Coockies and History. Click delete.

    Restart the browser.

    Also remember that after installing a UR you will need to close existing sessions and then re-oen to get the changes.

    Thanks & Regards,

    Khaja Mohiddin

    Wednesday, April 11, 2012 9:03 AM
  • Hi,

    thanks for the answer.

    I have cleared the cache of the browser several times, but the error still arises.

    Do you have any other idea ?

    Wednesday, April 11, 2012 10:21 AM
  • Did you restart the CRM server after updating the Rollup?


    Khaja Mohiddin

    Wednesday, April 11, 2012 12:15 PM
  • We have restarted the CRM server after the rollup.

    I had to open a case to Microsoft. They are investigating on this topic.

    Wednesday, April 11, 2012 3:56 PM
  • Okay, please share the solution once you resolve the issue.


    Khaja Mohiddin

    Wednesday, April 11, 2012 4:26 PM
  • Microsoft provided me a workaround.

    My problem was that I opened the page from my aspx page using the window.open method, giving the URL and, as second parameter, "mywindow".

    The suggested me to modifiy "mywindow" into "_top" and it worked like before the rollup update.

    Thursday, April 12, 2012 2:25 PM
  • For the record this workaround (for what appears to be a custom aspx page) is not valid for the original issue that was observed from hyperlinks in CRM reports. Using _top to make the 'masterWindow' reference valid is not an option for report hyperlinks (including out-of-box report links) that use the drillopen.aspx page.


    Thursday, April 12, 2012 4:59 PM
  • Ken, we are experiencing the same issue.  When the issue is resolved could you please post the fix or workaround?  Thanks,
    Tuesday, April 17, 2012 12:11 PM
  • Thanks Simon, I am going to try that rof=false as a workaround for our report hyperlinks. Dale - you might want to check out the thread Simon linked above as well. I'll report back if that turns out to be a valid (but painful) workaround for us.
    Thursday, April 26, 2012 3:06 PM
  • Ken, That fix did not work for us.   As a temporary workaround we commented out the Mscrm.CrmWindow.$1z_0[etc]=mode; line in the setFromMode method in CRMReports/rsviewer/rsviewer.aspx.  This is an unsupported change.  We stepped thru the JS code and based on what it was doing we felt that was commenting out the line ok was as a temporary workaround. 

    Please let us know if Simon's solution works for you and any thoughts may have on our temporary solution.

    Thursday, April 26, 2012 3:27 PM
  • Sorry for the late reply - that fix (in the link) didn't work for us either. I /thought/ we were going to just get by with UR6 until this was addressed but we may be forced to upgrade sooner, so it looks like I'm going to actually try YOUR workaround :) I'll let you know later this week if we have any issues with it, although by now you've probably gone ahead and deployed.

    Tuesday, May 29, 2012 11:06 PM
  • Commenting out the setFormMode line did not help me either. Here is the tentative, TOTALLY UNSUPPORTED hack that makes this work for us (so far).

    The root of the issue is the masterWindow() function in global.js - we observed two problem scenarios

    1. When clicking on 'Reports', opening a report, and clicking a hyperlink that opens a form. That form has all kinds of problems, such as clicking a lookup hyperlink does nothing, and subgrids do not load.

    2. When embedding a report into a form, and clicking a hyperlink, same results as #1 above, the opened form is not fully functional.

    What we ended up doing is adding a section to the global.js masterWindow() function to try hooking up to window.opener.parent before trying window.opener, which SEEMS to fix our issues in both cases above, but I have no idea what regressions we may have introduced.

    I am NOT going to use this unless we are /forced/ to apply a rollup beyond UR6 before this bug is fixed by MS. Here's my hacked up version of masterWindow() - the try/catch section is what I added. I had to add it BEFORE the window.opener check due to the way the issue manifests.

    function masterWindow(){var $v_0=window.self._masterWindow;if(isValidWindowInstance($v_0))return $v_0;if(isValidWindowInstance(window.top)&&window.top!==window.self){$v_0=window.top.masterWindow();if(isValidWindowInstance($v_0))return $v_0}try { if (isValidWindowInstance(window.opener.parent)) return window.opener.parent } catch (e) { }; if(isValidWindowInstance(window.opener))return window.opener;return window.self}

    Wednesday, May 30, 2012 3:37 PM
  • Ken,

    Not sure if this will help or not but a MS Premier engineer told us it was fixed in rollup 8 but we haven't applied that rollup and probably won't for sometime. Best of luck!

    Wednesday, May 30, 2012 4:28 PM
  • Hi,

    I am facing the same problem and we have just installed rollup 8 in the hope that this would be resolved, but unfortunately this error is still around.

    Thursday, June 14, 2012 1:09 PM