2009-11-23 22 views
6

Znaleźliśmy interesujący problem między ASP.NET 3.5 i ReportViewer z Google Chrome. Nasz zestaw stron działa poprawnie, dopóki formant ReportViewer nie wyświetli raportu.ASP.NET ReportViewer Wykorzystanie procesora Google Chrome

Google Chrome pobiera wtedy 50% CPU, nie robiąc nic.

Wygenerowałem formant ReportViewer do pustego projektu Web Forms, aby potwierdzić jego kontrolę, a nie fałszywego fragmentu mojego kodu.

Używam ReportViewer w trybie lokalnym (plik RDLC), więc zakładam jego wersji 2005?

Ktoś widział to wcześniej i miał rozwiązanie?

Phil

Edit: Google Chrome 3.0.195.33 na x64 Vista Business

Edit 2: Dodano Bounty za pomocą mocowania to

+0

Nadal nie ma akceptowalnych odpowiedzi lub rozwiązań, co jest wyraźnie czymś w kontrolce ReportViewer w trybie lokalnym, które to powoduje. Nadal nie udało się znaleźć odpowiedzialnej części :( – Phil

+0

Również dzieje się w Safari dla Windows - pachnie jak błąd WebKit do mnie! –

+0

Używam go w chrome 19 i działa dobrze normalnie, ale kiedy otwieram narzędzia programistyczne (Inspect Element), aby sprawdzić jego klasy css, a następnie staje się głodny pamięci i strona internetowa nienormalnie zaczyna zużywać setki MB do 1,5 GB i zawiesza się.Musimy ręcznie zabić stronę za pomocą Menedżera zadań. – MaxRecursion

Odpowiedz

8

Rozwiązaniem jest w rzeczywistości niektóre z ReportViewer JavaScript powoduje nieskończoną pętlę w Chrome, publikuję kod źródłowy, jak rozwiązać ten problem, tworząc niestandardową wersję kontroli ReportViewer i naprawiając uszkodzony JavaScript (mam zgubiłem link do rozwiązania, ale nie napisałem tego, tylko go użyłem :))

Mogę potwierdzić, że teraz uaktualniliśmy do najnowszego ReportViewer w Visual Studio 2010, problem z procesorem Chrome już nie istnieje i ta praca nie jest wymagana.

public class MyReportViewer : Microsoft.Reporting.WebForms.ReportViewer 
{ 
    protected override void Render(HtmlTextWriter writer) 
    { 
     using (StringWriter sw = new StringWriter()) 
     { 
      HtmlTextWriter tmpWriter = new HtmlTextWriter(sw); 
      base.Render(tmpWriter); 
      string val = sw.ToString(); 
      val = val.Replace(@"!= 'javascript:\'\''", @"!= 'javascript:\'\'' && false"); 
      writer.Write(val); 
     } 
    } 
} 
+0

Tak, działa jak urok. –

+0

Link do rozwiązania: http://productforums.google.com/d/msg/chrome/XyOh1fDq_GA/ggPKU19_0ycJ – MaxRecursion

+1

Musiałem dostosować rozwiązanie nieznacznie: 'val = val.Replace (@"! = ' javascript: \ ' \ ' ' "@ "= ' javascript: \ ' \ ' ' && fałszywego");' może wynikać z innej wersji SSRS – Johann

0

miałem ten problem i to doprowadzało mnie absolutnie szalony!

Przede wszystkim zapisz wygenerowany plik - to jest, jeśli możesz. Czasami zawiesza się. Zapisz i sprawdź rozmiar generowanego raportu. Mój problem został zresetowany w plikach o wielkości przekraczającej 16 MB i spowalniał przeglądarkę i sieć.

Zrób sobie przysługę zajrzyj do html, wyświetlając źródło, które jest generowane w formularzu internetowym. Sprawdź, czy styl został napisany bezpośrednio w linii w wygenerowanym dokumencie, a nie w pliku.

Spróbuj usunąć stylizację z raportu i sprawdź, czy to pomaga.

1

Na forach Google Chrome mówi się o tym wątku. Nie wiem, czy możliwe jest uruchomienie raportu na serwerze zamiast lokalnie, co wydaje się naprawić problem. Oto wątek: ReportViewer rendering maxes out thread CPU usage

+0

Nie jako opcja, ponieważ dane pochodzą z wielu różnych miejsc i musi zostać przetworzony, a następnie powiązany jako źródło danych obiektu. – Phil

0

Podczas gdy Chrome jest ładną przeglądarką i rozwija się dość szybko, obawiam się, że na razie nie ma innego rozwiązania niż użycie innej przeglądarki. Sądzę, że Google będzie pracował nad tym problemem, ale na razie nie jest naprawiony.

Sądzę, że spróbują naprawić inne problemy. Widziałem inne strony renderowane w dziwny sposób z chromem, a nie z IE.

1

Jeśli używasz Menedżera raportów, takiego jak ja (wersja 2005), niewiele można zrobić o formantu ReportViewer. (czy istnieje?) Istnieje jednak alternatywa:

Rozwiązanie Phil skutecznie dezaktywuje kod uruchamiany przez zdarzenie onload elementu iframe.W SSRS 2005 jest to iframe z id „ctl140TouchSession0”:

<iframe name="ctl140TouchSession0" id="ctl140TouchSession0" onload="if (frames['ctl140TouchSession0'].location != 'javascript:\'\'') frames['ctl140TouchSession0'].location.replace('javascript:\'\'');" src="javascript:''" style="position:absolute;width:0;height:0;border-width:0;visibility:hidden;"> 

Można zobaczyć kod przestępstwa w przypadku onload - kod Render wyłącza if dodając „& & false” do stanu.

Następujący javascript wykonuje to samo, opróżniając po załadowaniu strony, zatrzymując pętlę.

(Add to na dole [MSSQL usług Reporting Folder] \ ReportManager \ js \ ReportingServices.js)

// CUSTOMIZATIONS 
addLoadEvent(customize); 

//some browser-independent onload-adder I pulled from somewhere 
function addLoadEvent(fn) 
{ 
    if (window.addEventListener) 
     window.addEventListener('load', fn, false); 
    else if (window.attachEvent) 
     window.attachEvent('onload', fn); 
} 

function customize() 
{ 
    //the actual fix. 
    //check first, we may be in a page without a reportviewer 
    if(document.getElementById('ctl140TouchSession0')) 
     document.getElementById('ctl140TouchSession0').onload = ""; 
} 

Uwaga: Nie jestem pewien, co zdarzenie onload faktycznie robi, a jeśli tak to usunięcie zabija inne funkcje. Powinien istnieć jakiś sposób zmiany obciążenia w taki sam sposób, jak rozwiązanie Phila lub poprawka zależna od przeglądarki, ale to działa, a ja nie napotkałem jeszcze problemów w IE.

0

To zadziałało dla mnie, ale nie polecam tego. Zauważyłem, że mój WebKitInspector spowodowałby zawieszenie przeglądarki.

var iframes = document.getElementsByTagName("IFRAME"); 

for (var i = 0, ln = iframes.length; i < ln; i++) { 

    iframes[0].parentNode.removeChild(iframes[0]); 
} 
1

Jeśli mamy zmienić typ doc od:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"> 

do:

!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 

działa na chromie ale przestaje działa na IE.

+0

Robert

+0

Reportviewer nie wyświetlał się w Chrome i Safari, ale działał dobrze w IE i Firefox. Właśnie usunąłem dodatkowe wartości w Doctype i zachowałem tylko! DOCTYPE> i to działało dla mnie – Robert

Powiązane problemy