As you’re thinking about or discussing the announced CRM cross-browser support coming in R8 (Q2 2012) be aware that there are some expectations that may or may not be realistic.
If you expect users in your organization to use browsers other than IE to access CRM, it's important to be ready to understand what is supported out of the box - and what modifications to your existing customizations will enable users to get the most out of CRM, regardless of their browser choice.
Beyond this list of suggestions there was an excellent technical presentation on coding for Cross-Browser compatibility presented by Karun Krishna from Microsoft India to the XRM user group – if you go to their site (http://www.xrmvirtual.com/), the presentation is available for review/download here http://www.xrmvirtual.com/events/Cross_browser_dev.
Setting Expectations
1) In every project, if additional browsers (beyond IE) are to be implemented, be sure to allow additional time to code and validate. – Cross-browser support for customizations is not automatic and cannot be assumed.
2) “Universal” cross-browser support of CRM is not the promise of R8.
a. There are some areas of CRM that will still only be available through IE – such as Customization/Administration features and the Workplace and Service Scheduling calendars.
b. Not *every* browser is supported. (e.g. Opera and old versions of Firefox .)
c. They’re putting a lot of effort into iPad support (using Safari) – but it still has extra caveats due to the special nature of the iPad environment. (no pop-ups, no file upload, no ‘right-click’, no Silverlight, no ActiveX, etc.)
Notes for CRM Customizers:
Unsupported script/DOM hacks -
Unsupported client-side code to perform *special* formatting – will likely break as soon as R8 is applied.
i. Just because something works now, don’t assume it will work post R8 – even in IE.
ii. If you’re not sure if a particular ‘trick’ is based on supported code, ask. (or assume it isn’t)
iii. There is much more discussion about jQuery – if you are new to jQuery (like I am) – It’s a worthwhile skill to learn.
XRM.* vs. crmForm.all.* Style of scripting API
For client-side jscript customizations, only the 2011 style of the SDK is supported: (xrm.Page.*)
i. Tons of blog post examples and code snippets that are floating around were written originally for 4.0, but are supported in 2011. – They will continue to work in CRM 2011, but only in IE.
ii. There are some nice tools out there to convert CRM 4.0 script into CRM 2011
iii. All new jscript code in your projects should be in the xrm.* style (http://msdn.microsoft.com/en-us/library/gg328474.aspx ) both to ensure cross-browser support, but also compatibility beyond the current version. (The “crmForm.all.*” style of API interaction is only supported for code that was upgraded from 4.0 – it’s now deprecated and should be migrated whenever you are updating form scripts. – the 4.0 script-conversion tools listed above are great for updating your code to the XRM style.)
In Summary
As with anything still in development, expect changes – but the information here seems to be stable and as reliable as can be expected at this point.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Cookie settingsACCEPT
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.