How compatible is the MS Report Viewer Control with browsers like Firefox and Safari?
Please also post if you know any 3rd party report viewers for SSRS.
How compatible is the MS Report Viewer Control with browsers like Firefox and Safari?
Please also post if you know any 3rd party report viewers for SSRS.
I have not noticed any real issue with it being displayed in Firefox or Safari. At times I think it might be getting rendered better in Firefox, but I don't have any actual benchmarks to back that up.
Edit - 2016/2017 Update
SSRS 2016+ can be said to be cross-browser compatible.
Table borders aren't displaying right in IE10, but IE10 is dying out anyway.
In the rest of the browsers, it's fine.
You still need to register
add_pageLoaded
to translate the parameter prompts.Also, like in versions < 2016, you need to add
PageCountMode="Actual"
toRS:ReportViewerHost
control.if you want to have meaningful paging numbers.
Also, there's a problem when you set the language in the query string with datepickers (with SSRS < 2016 as well). You need to set
context.Request.UserLanguages[i]
to the language specified in the query-string in context.BeginRequest in a HTTP-Module, if you want datepicker to work with a non-browser language.Also, you need to add the X-Frame-Options and Content-Security-Policy HTTP-headers in each HTTP-response, if you want to use SSRS in an iframe in the internet securely. See my github-repository for details.
Pre-2016:
I can tell you, I have 9 years experience with the damn thing (SSRS 2005, SSRS 2008 R1 & R2, 2012, and SSRS 2014).
Let me assure you that because SSRS HTML reports depend on IE5-Quirksmode, there is no chance in hell they will ever render correctly in any browser other than Internet Explorer (IE < 10 I might be inclined to add).
IF you have admin access to the reportserver, and I stress the IF, you can add jQuery routines and CSS on the ReportViewer page to correct the most basic problems (like that you don't see more than 1cm of the report), but otherwise, the HTML rendering will still look absolutely horrible (margins, table borders, picture paddings, column size, textfield-size, title and/or pagenumber-alignment, etc., in short - just about anything)
Of course, the ActiveX printer control can only ever work in InternetExplorer (on Windows), because only there ActiveX are supported.
Let me also assure you, there is absolutely no way in hell to get ReportManager working in any other browser than IE.
As for Internet Explorer support, it should be mentioned, that starting as of IE version 10, IE defaults to webkit-quirksmode (for compatibility reasons) instead of IE5 quirksmode, so the HTML rendered will look equally horrible as in Chrome/Firefox/Safari for IE 10+, unless you added meta xua-compatible IE5 in the ReportViewer.aspx page.
The latter might not apply for Intranet, as IE automatically falls back to IE 7 compatibility mode when it's on an intranet site (but only in any Windows version < 8).
In Windows 8, localhost links and computername links (can't add the http:// in stackoverflow posts) are not assigned to the local intranet zone (probably as quick hack so IE doesn't fall back to IE7 compatibility mode), and therefore, Windows authentication will FAIL.
It should also be mentioned that it's not possible to add meta xua-compatible IE5 for ReportManager, because there is no page you can edit (compiled non-updateable ASP.NET website-project... ).
And that short of using the dev-tools to switch reportmanager in quirksmode, it's not possible to use ReportManager in IE 10+.
Then, another thing to mention is, that starting as of IE9, IE inherits the doctype of iframe elements from the parent page, and there is no way in hell to change that either (without changing the parent page to the desired child-page doc-mode).
So if you were clever enough to use iframes for the reports, because there is no way in hell any sane person wants popups in the age of popup-blockers, the report page will inherit the parent page's doctype. If that isn't IE5-QuirksMode, it will render the reports equally horrible as on Safari/Chrome/Firefox/Opera for any IE > 8, irrespecive of any possible meta xua-compatible ie5 tag in ReportViewer.aspx.
As for alternatives, for free and with a similar feature-set, there is only Eclipse BIRT (fortunately, the HTML rendering isn't similar).
It should be mentioned that BIRT, although licensed under the Eclipse Public License, uses SUN Java and therefore you are using Oracle technology, which is subject to its respective licensing terms.
Also, you are using non-Microsoft technology, and the Excel-Sheets BIRT renders are actually XML files, which will produce (who would have guessed) a rather alarming warning when opening in Office 2010+.
Then, for a rather large fee, there is http://www.stimulsoft.com reports, and Telerik reports.
From the technical looks of it, I'd recommend stimulsoft reports, but: disclaimer, i haven't used either of these, because they aren't free.
As for alternative SSRS rendering engines (not viewers btw), there is only www.fyireporting.com/, which has a fork here http://www.codeproject.com/Articles/138271/An-Open-Source-RDL-Engine.
But fyiReporting is incomplete and work in progress (if not abandoned), so I would refrain from using it.
Bottom line, if your product is IE & windows only, with windows version < 8 (and no - not <= just in case you haven't been paying attention), in intranet, called from pop-ups and not iframes, then go with SSRS.
For anything else, use stimulsoft reports (the problem is, you have to redo all your reports, as there is no automated migration - not even a non-working one).
PS:
And by adding "a little javascript", i mean the below thing(2008 R1 Edition, won't work on 2008R2+, may work on 2005, and note that you need to embed jQuery and jQuery Migrate in an inline-script tag, if the client PC's don't have access to http(s)://ajax.aspnetcdn.com [note: putting the scripts into the Pages folder and adding a relative or absolute link won't work...]):
Note: UpdateLock stems from 2012 backport and is not really used here, and language stems from backport too, setInterval on TranslateParameterPrompts is necessary in 2012 and function for 2012 has only the little addition of "label" in the jQuery selector...
Infering the language from the browser language goes like this, btw:
And in 2012 you need to Dispose of the session cookies, otherwise you get "HTTP 400: Header too long" after opening about 120 reports:
And on 2012, you need to listen to content update, because it uses Microsoft Ajax controls
And note that for 2012, setTableSize is alterTableBorderWidth, and the selector goes like this:
Btw, if you want to remove the PRINT icon, because it's only a source of sorrow, that goes like this (for German, English, French and Italian [the languages spoken in Switzerland + English]).
This CSS is for 2008 R1, don't know and care if it's the same in 2012.
And if that still doesn't deter you, then go right ahead and use forms authentication in SSRS 2012 (hint 1: there is no ms-provied sample as for 2005-2008R2, you need to write it yourself) ;)
Hint2: if you followed hint1, forms authentication redirect doesn't work when you have a colon in the URL [bug?], you can steal the code from mono and write your own redirect.
Hint3: if you followed hint2 and got forms authentication working, then you probably want to change the upload tool you're going to write, because you won't like to do manually "for each report browse-directory - check allow override checkbox - upload report - set datasource) for 120 reports or so, then you will be inheriting a class from ReportingService2005 and override GetWebRequest and GetWebResponse
Hint 4: The above methods won't work if you haven't installed service pack 1 + 2 on SSRS 2008 R2...
Hint 5: The TranslateParameters method is there because you cannot (by design) translate the parameter prompts to multiple languages by SSRS, so you write:
which uses schema:
And then do split by '/' on the text (which is a little error prone if your prompt text contains '/' somewhere), and then select the right text by index of the language, by choosing MIN(splitarray.length, index) btw, just in case somewhere you only have Text_DE / Text_FR or whatever, first checking if the text contains a '/' at all, of course.
Hint 6: Need I go on ? (i could still expand this post to tenfold size, but I think I should go back to work now :) )
If you want to see just how f*up it looks, this is how vanilla ssrs renders in chrome
This is what it looks like in IE11, with IE5 compatibility set via xua
And this is what it should be, and what you can get it to render with much tinkering with javascript and CSS
Addendum:
Oh, and it gets even better
If you want to run reportviewer in a language specified by your application (which is NOT identical to the browser language), you need to set the culture of reportviewer to the culture specified in your query string...
If you want to set a static culture, you can do so in the page declaration
And if you try to remove the the print icon and the atom-feed, doing it with styles, no matter how, it only works in Chrome...
But you can actually remove at least the print icon in internet-explorer by adding
ShowPrintButton="false"
to the reportviewer control:Another idea: in SSRS 2012 & 2014 (and possibly 2008R2), you can also add your SSRS-fixing javaScript method into add_pageLoaded of ScriptManager. Like this:
Then you don't have to listen to page change events, which speeds things up, because loaded is only called once at the end of each update.
WARNING
Because in the Internet, IE doesn't default to compatibility view,
won't help you with certain issues either (rotate270 text/vertical text).
Even in IE, it only works properly when you are in the intranet, because only then it uses "compatibility view". While the meta-tag sets the brower into IE5-Quirksmode, it doesn't enable "compatibility view", so it isn't the true quirksmode...
Rendering issues exist with Firefox, Chrome and Safari. I know for Firefox and Chrome, there are IE Add-ins that allow you to run the report in a Firefox/Chrome tab.
See the following MSDN articles for browser compabilities and the ReportViewer controls:
SSRS works perfectly on IE6,7,8. It works on Firefox and Safari, but with displaying issues.
There are two possible solutions to fix those, test and see whichever works for you.
Solution 1
Go to
Update style as
Solution 2
Add following changes to stylesheet:
From the hip and perhaps a little stale. ASP.NET used to treat any non IE browser as a box of rocks. May be worth looking into if your experience problems.
http://weblogs.asp.net/fmarguerie/archive/2005/01/04/346222.aspx