Indeed, the workaround Jeff found is a completely valid one. Actually it is very close to the first workaround I suggested with the difference that real files are used instead. Let me explain:
The problem you encounter happens because for some reason the after-AJAX-call-registration of the client-side code of the controls fails in Safari.
This registration is a result of the control being initially invisible and the accompanying <script>
tags being output the first time the control becomes visible. Please note, that the src
attribute of these <script>
tags is valid, e.g. if you make a request to the server using that URL
, you will get the proper content.
When you set <asp:ScriptReference>
definitions to the ScriptManager
, the ScriptManager
control initially outputs the <script>
tags, corresponding to the ScriptReferences.
This is why there is no need for their registration after the AJAX call (for the same reason the ScriptManager
does not even attempt to register them, which removes the condition for the error to happen).
As per Jeff's workaround - the approach is actually the same (he also registers the ScriptReferences
to the ScriptManager
). The difference is that he defines a Path
attribute to each ScriptReference
. When the ScriptManager
meets such a ScriptReference
, it resolves the specified path and includes a <script>
tag, pointing to the physical file. When the physical file approach is used, the notifyScriptLoaded()
call is needed to have the client-side code work with Ajax requests (this is done automatically by the ScriptResourceHandler
if the non-file approach used).
In general, in Jeff's workaround the <script>
tags get included to the page initially too.
I want to note something: as a control vendor we always strive to make our products work with minimal configuration and additional steps, which could possibly increase the complexity of a future update. This is the reason we don't suggest manual script registration unless no other way to solve the problem - we really want to help you deliver more than expected.
I hope this helps.
the Telerik team