reporting services - services - SSRS 2008 R2-SSRS 2012-ReportViewer: Informes en Safari/Chrome, pero funciona bien en Firefox/Internet Explorer 8... ¿por qué?
reporting services url parameters (17)
Solución basada en CSS
Pude agregar lo siguiente a la hoja de estilo para Reporting Services, y me lo arregló en Chrome.
Descargo de responsabilidad: Esto no se ha probado exhaustivamente para la compatibilidad entre navegadores.
/**************CHROME BUG FIX*****************/ div#ctl31_ctl09, div#ctl31_ctl10 { overflow: visible !important; } /*********************************************/
Agregue eso al principio del archivo ReportingServices.css
.
Para mí, ese archivo se encuentra en:
C:/Program Files/Microsoft SQL Server/MSRS10_50.MSSQLSERVER/Reporting Services/ReportManager/Styles/ReportingServices.css
Tengo algunos informes simples en SSRS 2008 R2
, pero no se mostrarán en absoluto en Safari o Chrome. Según los Libros en pantalla de Microsoft, estos navegadores son compatibles de manera limitada. Sin embargo, no puedo ver nada después de que se complete el reloj de "Carga" de datos. La barra de parámetros y la sección de navegación de migas de pan en la parte superior de la página están todos allí. Además, puedo guardar / exportar a cualquier formato en Safari y Chrome. Simplemente no mostrará la sección del informe en sí, que está en blanco.
¿Se supone que debo usar certificados y conexiones seguras (actualmente no configurado con HTTPS, solo HTTP)? ¿Hay alguna configuración del lado del servidor que deba modificarse? ¿Alguien ha tenido éxito al mostrar CUALQUIER reporte en Safari / Chrome usando versiones anteriores de SSRS (2005)?
Estoy usando Safari 5.0.4
y Chrome 10.0.648.151
. Sé que la similitud de estos dos buscadores es que ambos se basan en WebKit .
El informe se procesa con éxito en Internet Explorer 8 (por supuesto) y Firefox 4.0.
Realmente apreciaría si alguien puede arrojar algo de luz sobre esto.
Solución basada en CSS para todo el sistema
Esto no requiere ningún marco de JavaScript o Ajax ni ningún otro contenedor. Fue probado en Internet Explorer, Firefox, Safari y Chrome.
Esto se puede arreglar en el nivel de la Hoja de estilo en el Servidor de informes.
Primero, navegue al directorio donde están instalados los servicios de creación de informes, en mi caso ( SQL Server 2012 SP1) es:
C:/Program Files/Microsoft SQL Server/MSRS11.MSSQLSERVER/Reporting Services/ReportServer
En ese directorio, encontrará un archivo llamado reportserver.config.
Consulte Personalizar hojas de estilo para HTML Viewer y Report Manager .
En ese archivo inserte una sola línea XML como (del documento anterior):
<Configuration>
...
<HTMLViewerStyleSheet>SafariChromeFix</HTMLViewerStyleSheet>
...
</Configuration>
Salva eso.
Lo que no le dicen en el enlace de arriba es que esta entrada anula completamente la hoja de estilo predeterminada. Mis primeros intentos de hacer que los informes funcionaran al agregar una hoja de estilos div, todo lo demás se rompió. Una vez que descubrí que esta edición en el archivo reporserver.config no aumentaba, pero en realidad reemplazaba la hoja de estilo predeterminada, copié en la hoja de estilos predeterminada y todo comenzó a funcionar.
A continuación, desciende al directorio Estilos ( C:/Program Files/Microsoft SQL Server/MSRS11.MSSQLSERVER/Reporting Services/ReportServer/Styles
).
Haga una copia del archivo llamado SP_Full.css y nombre la copia SafariChromeFix.css. En este punto, SafariChromeFix.css debe ser idéntico a SP_Full.css.
Edite SafariChromeFix.css y agregue las siguientes líneas a la parte superior:
div {
overflow: visible !important;
}
Guárdalo
Una vez que se haya guardado, todos los informes existentes en esta instancia de Reporting Services se mostrarán en todos los navegadores, incluidos Chrome y Safari.
Tenga en cuenta:
No solo es posible, sino que es muy probable que reportserver.config se sobrescriba con actualizaciones de los servicios de informes, por lo que es posible que deba agregar la <HTMLViewerStyleSheet>SafariChrome</HTMLViewerStyleSheet>
con el tiempo.
Esto también nos da un lugar para entrar en la hoja de estilo predeterminada y hacer muchos otros cambios personalizados a partir de algo que ya está funcionando. Y como no es la hoja de estilo predeterminada, su nuevo archivo CSS personalizado no se sobrescribe durante las actualizaciones y parches.
Solución definitiva (¡también funciona en SSRS 2012!)
Agregue la siguiente secuencia de comandos a " C: / Archivos de programa / Microsoft SQL Server / MSRS10_50.MSSQLSERVER / Reporting Services / ReportManager / js / ReportingServices.js " (en el servidor de SSRS):
function pageLoad() {
var element = document.getElementById("ctl31_ctl10");
if (element)
{
element.style.overflow = "visible";
}
}
En realidad, no sé si el nombre del div es siempre ctl31_ctl10
: en mi caso lo es (en lugar de SQL Server 2012 azzlak found ctl32_ctl09
).
Si esta solución no funciona, consulte el código HTML de su navegador para ver si el script ha funcionado correctamente cambiando el desbordamiento: propiedad autodesbordante: visible .
Solución para el control ReportViewer
Inserte esta línea de estilo en la página .aspx
(o en un archivo .css
vinculado, si está disponible):
#reportViewer_ctl09 {
overflow:visible !important;
}
Razón
Chrome y Safari representan un desbordamiento: automático de diferente manera con respecto a Internet Explorer.
El HTML de SSRS es HTML de QuirksMode y depende de errores IE 5.5. Los navegadores que no son IE no tienen el IE quirksmode y, por lo tanto, procesan el HTML correctamente
La página HTML producida por los informes de SSRS 2008 R2 contiene un div que tiene desbordamiento: estilo automático , y convierte el informe en un informe invisible.
<div id="ctl31_ctl10" style="height:100%;width:100%;overflow:auto;position:relative;">
...</div>
Cambiando manualmente (usando la ventana de depuración de Chrome) desbordamiento HTML final : desbordamiento automático : visible puedo ver informes en Chrome.
Amo la solución de Tim ; es fácil y funciona.
Pero todavía hay un problema: cada vez que el usuario cambia los parámetros (¡mis informes usan parámetros!) AJAX actualiza el div, el desbordamiento: la etiqueta automática se reescribe y ningún script lo cambia. Este detalle técnico explica cuál es el problema.
Esto sucede porque en una página creada con paneles AJAX, solo los paneles AJAX cambian su estado, sin actualizar toda la página. En consecuencia, los eventos OnLoad que aplicó en la etiqueta solo se activan una vez: la primera vez que se carga la página. Después de eso, cambiar cualquiera de los paneles AJAX ya no activará estos eventos.
Mr.einarq me sugirió la solución here .
Otra opción es cambiar el nombre de tu función a pageLoad.
Cualquier función con este nombre será llamada automáticamente por ASP.NET Ajax si existe en la página, también después de cada actualización parcial. Si lo hace, también puede eliminar el atributo de carga de la etiqueta del cuerpo
Entonces escribí el script mejorado que se muestra en la solución.
Desafortunadamente, la respuesta principal rompe las columnas flotantes (posición absoluta) en los informes de Internet Explorer. Por lo tanto, lo modifiqué un poco, lo que no me encanta, ya que busca específicamente WebKit, pero funciona:
//SSRS 2012 Chrome fix
function pageLoad() {
var element = document.getElementById("ctl32_ctl09");
var isWebKit = !!window.webkitURL; // Chrome or safari really (WebKit browsers).
// We don''t want to do this fix in Internet Explorer, because it breaks floating columns
if (element && isWebKit)
{
element.style.overflow = "visible";
}
}
El problema todavía existe en Chrome 22.0.1229.79.
YMMV , pero descubrí que eliminar la altura de la etiqueta ReportViewer corrige este problema.
Estaba teniendo este problema con los informes de SSAS, pero no con los de SSRS. No pude entender por qué hasta que revisé las diferencias en las páginas (un consultor había hecho los informes de SSAS). Estaba configurando ReportViewer Height = 60% y los informes de SSRS no especificaban la altura.
Una vez que eliminé la Altura, se muestran mis informes.
En mi caso, el DIV ofensor es "ctl31_ctl09", por lo que si la solución anterior no funciona, intente cambiar var element = document.getElementById("ctl31_ctl10");
var element = document.getElementById("ctl31_ctl09");
Este es un problema conocido . El problema es que una etiqueta div tiene el estilo "overflow: auto" que aparentemente no está bien implementado con WebKit, que es utilizado por Safari y Chrome (ver la answer Emanuele Greco). No sabía cómo aprovechar la sugerencia de Emanuele para usar el elemento RS: ReportViewerHost, pero lo resolví usando JavaScript.
Problema
Solución
Dado que "overflow: auto" se especifica en el atributo de estilo del elemento div con id "ctl31_ctl10", no podemos anularlo en un archivo de hoja de estilo, así que recurrí a JavaScript. Añé el siguiente código a "C: / Archivos de programa / Microsoft SQL Server / MSRS10_50.MSSQLSERVER / Reporting Services / ReportManager / js / ReportingServices.js"
function FixSafari()
{
var element = document.getElementById("ctl31_ctl10");
if (element)
{
element.style.overflow = "visible"; //default overflow value
}
}
// Code from https://.com/questions/9434/how-do-i-add-an-additional-window-onload-event-in-javascript
if (window.addEventListener) // W3C standard
{
window.addEventListener(''load'', FixSafari, false); // NB **not** ''onload''
}
else if (window.attachEvent) // Microsoft
{
window.attachEvent(''onload'', FixSafari);
}
Nota
Parece que hay una solución para SSRS 2005 que no he probado, pero no creo que sea aplicable a SSRS 2008 porque no puedo encontrar la clase "DocMapAndReportFrame".
La versión SQL Server 2014 de Reporting Services agrega soporte para el navegador Google Chrome, pero todavía no hay soporte para iOS. Ver detalles here .
Mi solución fue agregar el siguiente <script>
a:
Reporting Services / ReportManager / Pages / Report.aspx
El script se dirige al contenido principal del contenido del informe visible 1 y establece el style. overflow : visible
style. overflow : visible
cada vez que el informe carga 2, incluida la búsqueda a través de un informe de varias páginas.
if (window.addEventListener && document.querySelector) window.addEventListener("load", function () {
// drop out if Sys.Application.add_load is undefined
if (!window.Sys || !Sys.Application || !Sys.Application.add_load) return;
// register a function for when report data is loaded
Sys.Application.add_load(function () {
// get the report content control
var n = document.querySelector("[id^=VisibleReportContent]");
if (n) {
// get the report content control''s parent
n = n.parentNode;
if (n) {
// revert overflow:hidden to "visible"
n.style.overflow = "visible";
}
}
});
});
1 Esto significa que no tenemos que apuntar a los ID generados que tienen tendencia a cambiar, es decir: ctl31_ctl09
, ctl31_ctl10
, ctl32_ctl09
, etc.
2 Ver Sys.Application. add_load()
Sys.Application. add_load()
Nunca tuve suerte al mostrar informes en Chrome. La mayoría de la documentación de Microsoft ni siquiera lo incluye, así que supongo que Chrome debe tener problemas para interpretar algo en el ASP.
Consulte here .
Estoy ejecutando Chrome 11 y experimento el mismo comportamiento que tú.
Para SSRS 2012 en Windows Server 2008 R2 x64, un script de trabajo es:
function pageLoad()
{
var element = document.getElementById("ctl31_ctl09");
if (element)
{
element.style.overflow = "visible";
}
if (window.addEventListener) // W3C standard
{
window.addEventListener(''load'', FixSafari, false); // NB **not** ''onload''
}
else
if (window.attachEvent) // Microsoft
{
window.attachEvent(''onload'', FixSafari);
}
}
function FixSafari()
{
var element = document.getElementById("ctl31_ctl09");
if (element)
{
element.style.overflow = "visible"; // Default overflow value
}
}
Todas las versiones anteriores sugeridas no funcionaban en absoluto.
Para evitar tener que codificar el ID del elemento, edité el archivo ReportingServices.js en el servidor RS @ [Unidad]: / Archivos de programa / Microsoft SQL Server / [Instancia de Reporting Services] / Reporting Services / ReportManager / js / ReportingServices.js para incluir algún código para recuperar jQuery, cargarlo en la página y luego encontrar todos los elementos donde el desbordamiento se establece en automático.
Inserte el siguiente código en la parte superior del archivo ReportingServices.js
var loadjQuery = function (cb) {
if (typeof (jQuery) == ''undefined'') {
var scr = document.createElement(''script'');
scr.setAttribute(''type'', ''text/javascript'');
scr.setAttribute(''src'', ''http://code.jquery.com/jquery-latest.js'');
if (scr.readyState) {
scr.onreadystatechange = function () {
if (scr.readyState === ''complete'' || scr.readyState === ''loaded'') {
scr.onreadystatechange = null;
if (typeof (cb) === ''function'') {
args = [].slice.call(arguments, 1);
cb.apply(this, args);
}
}
};
}
else {
scr.onload = function () {
if (typeof (cb) === ''function'') {
args = [].slice.call(arguments, 1);
cb.apply(this, args);
}
};
}
var head = document.getElementsByTagName(''head'')[0];
head.insertBefore(scr, head.firstChild);
}
}
Luego, la siguiente línea después de eso es lo que originalmente estaba en el archivo JS.
Después de eso, agregue el siguiente código
var _rmFixReady = false;
function pageLoad() {
loadjQuery(function () {
_rmFixReady = true;
});
if (_rmFixReady) {
var overflowElements = $(''div'').filter(function () { return $(this).css(''overflow'') == ''auto''; });
overflowElements.each(function () {
$(this).css(''overflow'', ''visible'');
});
}
}
Acabo de terminar de probar esto con Chrome 27 e IE 10 en una instancia de RM2012 y funcionó muy bien.
Para mí, el nombre era " ctl32_ctl09 " (SSRS de SQL Server 2012 SP1, MSRS11).
Probé los enfoques y funcionó para mí, pero nuestros administradores de sistemas se mostraron escépticos sobre estos cambios.
En lugar de establecer la altura al 100% en ReportViewer
, utilicé una altura fija, y se las arregló para trabajar en mi aplicación para Internet Explorer y Chrome.
Tuve el mismo problema con ver los informes en Chrome. Lo arreglé agregando la extensión "Corrección del informe SSRS" a Google Chrome. https://chrome.google.com/webstore/detail/ssrs-report-fix/fjbdfjiheheafbioiejbdpalmojkeobk
Tuve que entrar en Chrome con F12 y noté que tenía ctl32 _ctl09, no ctl31_ctl09 en mi div.
Esto es para Windows Server 2008 R2 64 Bit con SQL Server 2012 . Agregue el script y luego reinicie SSRS y borre el caché del navegador.
// Fix para permitir que Chrome muestre los informes de SSRS
function pageLoad() {
var element = document.getElementById("**ctl32**_ctl09");
if (element)
{
element.style.overflow = "visible";
}
}
Un problema con el overflow:visible
solución overflow:visible
es que los encabezados flotantes están rotos en todos los navegadores. La siguiente secuencia de comandos dejará solo Internet Explorer y aplicará la corrección solo a los navegadores que no sean de Internet Explorer. Con esto, toda la funcionalidad se conserva para los usuarios de Internet Explorer y otros navegadores aún pueden ver los informes.
function pageLoad() {
var eval = getInternetExplorerVersion();
if (eval == -1)
{
var element = document.getElementById("ctl31_ctl09");
if (element)
{
element.style.overflow = "visible";
}
}
}
function getInternetExplorerVersion()
// Returns the version of Internet Explorer or a -1
// (indicating the use of another browser).
{
var rv = -1; // Return value assumes failure.
if (navigator.appName == ''Microsoft Internet Explorer'')
{
var ua = navigator.userAgent;
var re = new RegExp("MSIE ([0-9]{1,}[/.0-9]{0,})");
if (re.exec(ua) != null)
rv = parseFloat( RegExp.$1 );
}
return rv;
}