How come when debugging javascript in CRM 2011 for a form opened up from the ribbon, script blocks are created?

Question

Setup

I'm adding an appointment to a custom entity in an on site CRM 2011.

I click the "New Activity" button on the Ribbon, select Appointment, then Ok.
On the new window that opens, I F12 to open the IE debugger, and select the Script tab, set a break point both in my onLoad function, and in the crmForm_window_onload_handler of the FormScript.js.aspx file, and click the start debugging button.
I then reload the appointment window.

Issue

The break point in crmForm_window_onload_handler hits, but when I step into what should be the onLoad function of my custom js web resource file (appointment.js), rather than stepping into the onLoad function of my appointment.js file, it steps into the onLoad of an exact copy of my file, only it's name is script block (some random number from 0-99) ie script block(23). Why are these script blocks being created? In the on Save I'm also running this code:

Xrm.Page.getAttribute('new_issyncreqd').setValue(true);
Xrm.Page.getAttribute('new_issyncreqd').setSubmitMode("always");

But it's not actually saving and I'm guessing it's related to the script blocks...

Update

I did figure out why the code that is updating the IsSyncReqrdField is not working. This is for on Site CRM 2011 version V 5.0.9690.1992 (rollup 6). It apparently has a bug for the Appointment entity where it saves the entity first, then actually runs the custom onSave code. This is how it currently looks:

function crmForm_onsave_handler(eventObj,eventArgs)
{
  try
  {
    var eContext=Mscrm.FormUtility.constructExecutionObject(eventObj,0,eventArgs,null);
    eContext = Mscrm.FormUtility.constructExecutionObject(eventObj,0,eventArgs,eContext)
    Mscrm.Form_onsave();
    eContext=Mscrm.FormUtility.constructExecutionObject(eventObj,1,eventArgs,eContext)
    NEW.Appointment.onSave(eContext); // <-- My custom OnSave Handler 
  }
  catch(e)
  {
    displayError('crmForm', 'onsave', e.description);
  }
}

The bug is that the Mscrm.Form_onsave(); line is actually saving the record to the database, so when the custom event handler runs, it's already been saved, and any updates made in the custom event handler won't update the record.

The fix for this bug is to set bSaveInProgress = true; in the onLoad of the form, and then bSaveInProgress = !isValid; event.returnValue = isValid; in the onSave. The bSaveInProgress = true; will keep Mscrm.Form_onsave(); from actually saving the recrod and the event.returnValue will actually cause it to be created. It works and is a hack, but it's the only thing I've come up with to work around this bug...

The Problem Remains

Why are script blocks being created and executed instead of using the file that is already there?

Paul Way Paul Way · Accepted Answer · 2012-07-24T21:43:30

First, script blocks are created when inline javascript is coming from an XML or SVG file.

This is a known IE issue (scan for "script block"): http://msdn.microsoft.com/en-us/ie/ff959805.aspx

You can see the XML files, by usingthe "Network" tab in IE9 and then capturing a form load. There should be a few aspx files that are actually XML. An example is RenderGridView.aspx.

So the problem is that the aspx file is being retrieved again and then executing the inline function replacing the former script block (since javascript operates as a single global file).