Tìm kiếm hỗ trợ

Tránh các lừa đảo về hỗ trợ. Chúng tôi sẽ không bao giờ yêu cầu bạn gọi hoặc nhắn tin đến số điện thoại hoặc chia sẻ thông tin cá nhân. Vui lòng báo cáo hoạt động đáng ngờ bằng cách sử dụng tùy chọn "Báo cáo lạm dụng".

Learn More

crystal report not showing correctly in firefox after windows update

  • 9 trả lời
  • 13 gặp vấn đề này
  • 2666 lượt xem
  • Trả lời mới nhất được viết bởi jscher2000

more options

From the past six months, crystal reports has been displayed without the print toolbar and the formatting is completely lost in firefox. Previously we found that when we uninstall the windows updates KB2836942, KB2836943, KB2836946, KB2836947, the problem is resolved. But with more and more windows updates that are automatically updated on the servers, it is getting practically impossible to track which windows update creates the problem. There is absolutely no issue in Chrome, IE and Opera; it is only with firefox that this problem occurs; so we feel it is more of a firefox issue than a windows update problem. It is not just in one machine, but we found the same issue at all our customer's servers (more than 10). The servers are a mix of windows 2008, windows 2012 with iis 7. We also observed the same problem on windows 7 machines. We have been recommending firefox as the best browser for our software to all our customers, and with this problem cropping up, we are badly handicapped. Kindly let us know how to sort this issue. We have provided the link below for your perusal. When you open it in chrome it works fine, but on firefox it does not display correctly:¶mlist=@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

Tất cả các câu trả lời (9)

more options

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?

more options

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.

more options

Sorry for the late reply; The portion of the URL that has been modified is ¶ (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

more options

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 &

Được chỉnh sửa bởi cor-el vào

more options

Thank you for clarifying the address:,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.

Được chỉnh sửa bởi jscher2000 vào

more options

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

more options

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
more options

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.)

more options

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

Each contains this Note:

There is a configuration switch to be used to revert back to the old behavior:
<add key="aspnet:UseLegacyBrowserCaps" value="true" />

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...