I'm not sure about that URL. I changed the ¶ character to an & and tested in both Firefox and Chrome. Obviously the Firefox page is incomplete; it seems to be incomplete when sent by the server, judging from the page source (and confirmed in Fiddler). See screen shots.

The requests look largely the same. There is a small difference in the Accept headers but I don't know that these have any relevant to Crystal Reports:

• Firefox:
  
  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
  Accept-Language: en-US,en;q=0.5
  Accept-Encoding: gzip, deflate

• Chrome:
  
  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
  Accept-Encoding: gzip,deflate,sdch
  Accept-Language: en-US,en;q=0.8

I noticed the browsers seem to be referring to different .rpt files on the server:

• Chrome: Error in File C:\Windows\TEMP\RptProductWiseSalesDetails {6FF2ED89-548C-4A7A-8CF6-4E494E6A5312}.rpt

• Firefox: Error in File C:\Windows\TEMP\RptProductWiseSalesDetails {895C328B-6083-4C81-9BB9-D0AC77D9D970}.rpt

Not sure of the significance of or explanation for that. Is there something in ASP.Net that is processing requests from different browsers differently?

If I use the ua-site-switch extension to send a Chrome user agent to that server, I at least get the toolbar. (In your log, it will have LYING2U at the end.) Not sure why this should be necessary. I think I'll need to test on a different system.

Sorry for the late reply; The portion of the URL that has been modified is &para (ampersand with the word para has been replaced with a paragraph symbol; the name of the querystring is paramlist) We are not doing any processing specific to the browsers

That would probably be ¶ (¶) that is converted to an entity: ...reportname=RptProductWiseSalesDetails.rpt&paramlist=@FromDat,01/01/2011;

The same can possibly happen with &language: ⟨uage
Best is always to escape such & characters as &

Thank you for clarifying the address: http://54.209.141.3/Reports/Report.aspx?reportname=RptProductWiseSalesDetails.rpt&paramlist=@FromDat,01/01/2011;@ToDat,01/26/2014;@BranchSlno,1;@FranchiseSlno,1;@FirstCol,B;@DateType,B;@SaleChannel,A;@ProductTypeSlno,0;@ProductSlno,6;@ColorSlno,0;@FinancierSlno,0;@ChannelTypeSlno,0;@ChannelSlno,0;@SalesPersonSlno,0;@SaleStatus,L;@BillingType,A;@LoginUser,admin;@LoginBranch,Keerthi%20Triumph%20Bangalore;@Franchise,Triumph;@AddCustomerDetail,0;@SaleCodeSuffix,&loadfromsql=0

With default user agent in Firefox, no toolbar. With Chrome user agent in Firefox, I get the toolbar (screen shot attached; ua-site-switch extension).

Since that is the only change, I suspect something in the CR scripts on the server that is serving different pages to different browsers.

Edit: Unlinked the URL, to reduce potential for search engine indexing.

Hi jscher2000, any idea on how to solve the issue?

It looks that adding AppleWebKit to the user agent is sufficient to get the toolbar.
This works for me on Linux as a test UA:

• Mozilla/5.0 (X11; Linux i686; rv:27.0) Gecko/20100101 Firefox/27.0 AppleWebKit

I would think this that something in SAP's ASP.Net code needs to be modified, but I'm not a .Net developer, and it may well be a compiled component.

I noticed that you referenced four KBs. Are those updates to IIS? Perhaps there is a setting to counteract the problematic aspect. (I don't have time to review them at the moment.)

Those four updates all relate to the .Net framework, and involve how an ASP.Net application recognizes different browsers.

• http://support.microsoft.com/kb/2836942
• http://support.microsoft.com/kb/2836943
• http://support.microsoft.com/kb/2836946
• http://support.microsoft.com/kb/2836947

Each contains this Note:

There is a configuration switch to be used to revert back to the old behavior:

<appSettings>
<add key="aspnet:UseLegacyBrowserCaps" value="true" />
</appSettings>

I think the downside of turning off the changes is that IE 11 will not be well supported.

That's all I know so far...