Ok... I found the culprit here and very happy to know what is actually going on! Ill probably report this as a bug in Gemini soon.
Here is what is happening... A newer version of the dotnetnuke.webcontrols was released when DNN 5.x was released and this included new code for only rendering certain JavaScript files such as dnn.controls.js or many of the others such as the dnnmenu and so forth ONLY when a module uses a specific control. This is great but for the purpuses of the DNN Toolbar and so forth it wasn't always accurate.
Here is the bug:
1. Add into a module just the DNN Toolbar and DNN Label Edit
2. If no other modules or anything on the page loads, and the page is in view only mode, it will not (at least in several cases) render the dnn.controls.js file because it doesn't think it needs to. But... even if the toolbar/dnn label edit control isn't visible it still renders some code to the page. For example:
This is rendered to the page...
dnn.controls.toolbars['tbDynamicF']={btns:[{key:'edit',alt:'Edit',css:'eipbutton_edit',ca:'edit'},{key:'save',alt:'Update',css:'eipbutton_save',ca:'save'},{key:'cancel',alt:'Cancel',ca:'cancel'}],vis:-1,cssbh:'eipborderhover',css:'eipbackimg',cssb:'eipbuttonbackimg'};
So when this is rendered to the page and dnn.controls.js isn't then the user is given a JavaScript error.
This is because of this line of code in the DNNLabelEdit.vb file (similar in the toolbar file I think):
If IsDownLevel = False AndAlso Me.EditEnabled Then
DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference(Me.Page, DotNetNuke.UI.Utilities.ClientAPI.ClientNamespaceReferences.dnn_dom)
'DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference(Me.Page, DotNetNuke.UI.Utilities.ClientAPI.ClientNamespaceReferences.dnn_xml)
DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference(Me.Page, DotNetNuke.UI.Utilities.ClientAPI.ClientNamespaceReferences.dnn_dom_positioning)
DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference(Me.Page, DotNetNuke.UI.Utilities.ClientAPI.ClientNamespaceReferences.dnn_xmlhttp)
'If Not ClientAPI.IsClientScriptBlockRegistered(Me.Page, "dnn.controls.dnnlabeledit.js") Then
' ClientAPI.RegisterClientScriptBlock(Me.Page, "dnn.controls.dnnlabeledit.js", "<script src=""" & LabelEditScriptPath & "dnn.controls.dnnlabeledit.js""></script>")
'End If
RegisterClientScriptBlock(Me.Page, "dnn.controls.js")
RegisterClientScriptBlock(Me.Page, "dnn.controls.dnnlabeledit.js")
If ClientAPI.UseExternalScripts = False Then
ClientAPI.RegisterEmbeddedResource(Me.Page, "dnn.controls.dnninputtext.js", Me.GetType())
ClientAPI.RegisterEmbeddedResource(Me.Page, "dnn.controls.dnnrichtext.js", Me.GetType())
End If
'ClientAPI.RegisterStartUpScript(Page, Me.ClientID & "_startup", "<script type="text/javascript">dnn.controls.initLabelEdit(dnn.dom.getById('" & Me.ClientID & "'));</script>") 'wrong place
End If
So basically if you are NOT in edit mode then the dnn.controls.js file is never rendered. But... it does render JavaScript back whcih throws the error.
The work wround? The work round us to include another control that is not used in the module, just so DNN will know to render the dnn.controls.js file. So for example, including this in the ASCX file will make sure to render that.
<code><DNN:DNNMenu Id="myDNNMenu" RunAt="Server" Orientation="Horizontal"></DNN:DNNMenu></code>
Which really shouldn't be needed because the control isn't used.
-Chad