Insights

Turbo Form Rendering Engine Issues

Turbo Form Rendering Engine Issues


Sep 08, 2016

Turbo forms!  Turbo form introduction in MS CRM 2015 Update 1 has been a tremendous improvement in the form load event, because of the fact that the main window caches the IFRAME content both system scripts and the custom build web resources throughout the user session.  Prior to the turbo form introduction, any time we navigated away from a record to another the whole script would load in an IFRAME, meaning, navigating away from a record would discard the IFRAME contents resulting in reloading the resources fresh.
 
The Turbo form rendering is a sophisticated engine that makes use of the browser idle time to load the web resources much faster compared to the older versions.  The Dynamics CRM Team blog has an article explaining the architecture of the Turbo Rendering engine.
 
I am sure most CRM users are excited about the performance improvements in the form load.  With that being said, during this time since Turbo form introduction, we’ve had an option in the customization area to specify the usage of Legacy form rendering.  Now with the latest Microsoft announcement on the removal of Legacy form rendering option in the next major release, it is important for all environments that have extensive usage of JavaScript libraries to switch over to Turbo form rendering.  We at Wipfli have a methodical approach to handle the seamless upgrade from Legacy form rendering to Turbo form rendering mode.  In one of our recent upgrades, we have found a few issues using the Turbo form rendering engine, and I’ve highlighted a few of them as detailed below.
 
  1. Issue with Tab On Change Event
XRM API: Xrm.Page.ui.tabs.get(tabName).getDisplayState()
Bug Description: If there is any JavaScript functionality around Tab on Change event, you would notice a bug in that scenario.
 
Resolution: This issue is a known bug and the release vehicle would be Ara UR 2, the release dates are not available as of now.
 
  1. Issue With On Change event
XRM API:
Xrm.Page.getAttribute(“statuscode”).addOnChange(validateStatus);
Bug Description: An on change event configured from the script - for example in the above line of code, we have a function “validateStatusto be executed on change of a status code value.  If the form load has a functionality around resetting the statuscode value, then, the on change event “validateStatus” would fire in the On Load execution, which is a bug.
 
Resolution: The Microsoft CRM product team has completed the testing phase and the bug is resolved in Carina UR3.
 
We have a few more observations and bugs found which we are working on to get more clarity on the resolutions.  We will provide an update in our future blog post.  Please, keep following us on the Wipfli CRM Team Blog to find more about some of the unexpected behaviors as part of the Turbo form transition.  In the meantime, feel free to reach out to us with any specific questions.

Comments

Write a Comment

* = required fields

(will not be published)

(will not be published)

Dynamics CRM Blog

Subscribe to Connect – Microsoft Dynamics 365


Submit