Good day.
I have the following detail:
Make an application with signalR in vb.net (ASP.NET), which works well, the problem is that the page using SinalR has links that send me to other pages that open with a target = '_blank' in it browser, but when they open they do not load completely, when I inspect my page, the console sends me the following:
Active resource loading counts reached to a per-frame limit while the tab is in background. Network requests will be delayed until a previous loading finishes, or the tab is foregrounded. See https://www.chromestatus.com/feature/5527160148197376 for more details
I have researched how to disable that option in chrome, I have applied it, but when opening again pages do not load.
Any ideas?
Note: My chrome is version 69.0 and in IE the pages work correctly, and the end of the page show the next message (waiting for available socket)
Related
Summary
Environment: Windows Server 2016, IIS 10, ASP.NET webforms site, Wildcard SSL/TLS Certificate, IIS URL Rewrite 2.1 (MS supported download)
Goal: a) Determine and resolve the root cause(s) of the issue, b) [preferred] Get the two failing features working without users having to change settings on their browser, c) get the two failing features working, period, without first-time-processing issues on ubiquitous browsers (Chrome, FF, Edge, IE, Safari, Opera).
Issue Summary: Two of the site features i.e. downloading files and displaying SSRS reports fail with a first-time-processing error or fail entirely, depending upon the browser, with the SSL certificate bound to the site. Subsequent attempts to execute these features within the same browser window succeed in most cases. Various browsers fail in different ways and some don't fail at all depending upon the browser in question. Please bear with me as I try to provide details below.
NOTE: Both features work fine without the SSL certificate in the mix.
I have scoured the Internet for a solution to no avail and would be very grateful for any assistance on this.
Details
I have a client with an ASP.NET Webforms site containing file download and SSRS report display features. Users must be logged in to access these features. Sadly, the original developers implemented a rudimentary, homegrown approach for authenticating users i.e. it's not a "formal" authentication framework but, rather just a simple comparison of the provided username/password pair to the values stored in the database ... no formal authentication tokens are set to my knowledge ... could this be part of the issue?
Both of the aforementioned features have been working flawlessly for years using all current, major browsers. My client recently purchased a wildcard SSL/TLS certificate which I installed on the production IIS instance and configured the appropriate site bindings. In case this matters, the site is also using URL Rewrite with a basic rule in the web.config to modify all HTTP protocol requests to the HTTPS protocol.
All aspects of the site work fine with the SSL certificate in place except file downloading and SSRS report displaying. Current versions of Chrome and Firefox [Windows], and Mac browsers (I don't have first-hand access to a Mac environment) are exhibiting errant behavior. IE 11 (go figure) appears to be the only browser with no issues whatsoever. I have not tested Edge as I don't have access to that browser version.
File Downloading
The site has a feature that allows logged in users to download files from the site.
Chrome
Chrome displays a first-time-processing error "Failed - Network error" shown in the download status bar at the bottom of the browser. Clicking the chevron in the error message and choosing the "Resume" option from the context menu completes the download but, any attempt to open (double-click) the zip archive from its actual folder location results in the following error message: "Windows cannot open the folder. The Compressed (zipped) Folder '{path}' is invalid." Analyzing the zip file in a hex editor reveals that it contains the web page source code and not the intended file download. Repeating the file download operation in the same browser window works fine (culminating in a successfully downloaded, valid zip archive of files) and all subsequent file download attempts also succeed with no further issues for the remainder of the life of that browser instance. If the user closes their browser (all Chrome instances must be closed) and then re-opens Chrome navigating to the site, the browser, again exhibits the first-time-processing error and then works fine from then on for the remainder of the life of that browser window.
NOTE: All instances of the Chrome browser must be closed to reproduce the issue a second time. If the user leaves even one Chrome instance open on their computer and then navigates to the site using a new browser window and retries the file download, there are no issues. Perhaps Chrome is caching some kind of an authentication token? I am intentionally shying away from using the term "session" as the behavior does not appear to be session related. Opening a new tab within Chrome (after experiencing the aforementioned first-time-processing behavior) and navigating to the site (which culminates in a new session) does not exhibit the issue.
Firefox
Firefox displays a "Secure Connection Failed" error message when trying to download files from the site. All subsequent attempts continue to fail. This differs from Chrome's first-time-processing only behavior. Modifying the Firefox advanced preference "network.http.spdy.enabled.http2" from true (the default) to false permanently resolves the issue.
IE 11
IE 11 does not fail at all. No browser settings were altered from the default installation of IE 11.
Mac Browsers
Mac users report that file download attempts appear to succeed but attempts to open the zip archive culminate in the Mac environment thinking that the zip archive is password protected. NOTE: There is no explicit assigning of a password to the zip archive in the code that processes the download request. No users in Windows environments report this behavior.
SSRS Report Display
The site has a feature that allows logged in users to display a PDF document created at runtime from SSRS. The PDF displays directly in the browser window (as opposed to immediately initiating a download operation).
Chrome
Chrome displays a similar first-time-processing error when the user attempts to display an SSRS report. The browser displays the following error message: "Error Failed to load PDF document." The error message has a "Reload" button which culminates in the report displaying successfully. All subsequent attempts to display reports in the same browser window succeed with no further issues. The first-time-processing behavior is, again, experienced when the user closes and re-opens Chrome to the site, and retries the report display.
NOTE: It is interesting that in Chrome with either feature (file downloading or SSRS report display), once the user has experienced the first-time-processing issue with either feature, then the other feature works fine with no issues for the life of that browser instance. Example: User opens new Chrome instance, navigates to site, and attempts to download files. The file download will fail the first time. Immediately attempting to display a report succeeds ... and vice versa.
Firefox
Firefox displays the same "Secure Connection Failed" error message as was the case with the file downloading feature. Modifying the same Firefox advanced preference "network.http.spdy.enabled.http2" from true (the default) to false permanently resolves the issue.
IE 11
IE 11 does not fail at all. No browser settings were altered from the default installation of IE 11.
We have an Application Developed in ASP.NET inside which we have added an embedded Power Bi Dashboard using iFrame.
The Dashboard is working as expected in Chrome but facing the following issues with IE and Edge.
On IE the Dashboard is not being Displayed when viewed from the Embedded Application and upon clicking the power bi Sign-In button (shown within the Iframe), the application as a whole gets redirected to app.Powerbi.com/.... When you click the back button and refresh, still the sign-in prompt is shown in the iframe.
On Edge, the behavior is same as in IE, except that you click the back button from the app.powerbi.com website and then refresh the page, then the report renders correctly within the Iframe.
I tried clearing the Cache and Cookies, tried adding *.microsoft.com site and *app.powerbi.com to trusted sites list(per power bi forums) but still not working.
I suggest you check for the latest Windows updates and try to install it. Then after again try to test this issue on your side.
If the issue persists then hard refresh the page. Clear all the data for that site and again try to load the page.
I tested the issue with IE 11.1.18362.0 and Microsoft Edge 44.18362.1.0. As per my testing results, both browsers display the Power BI dashboard in ASP.NET site without any issue.
Output in IE 11:
Output in MS Edge:
If the issue persists then try to check the console to see whether there is any error or warning message. It can help to narrow down the issue.
I'm working on a legacy project that used Webforms. There is now a bug occurring on our production servers where a few of the web pages will show source code. I cannot replicate this on our test servers or by debugging it.
If it shows source code it will persistabtly show source code until the in-private/incognito window is closed and a new one is open.
It will occur about 50% of the time (out of 100 recorded tries it failed exactly 50).
This is a screenshots of some of the source code I'm seeing:
and
A commonality between the pages that break are that it uses AjaxControlToolkit, however there are other pages that use AjaxControlToolkit that aren't breaking.
Additionally, when I try to hit these pages they don't hit the page at all. If I'm not signed in they should redirect to the login page and they don't even do that.
I am writing my first ASP.net Web Application using VS2015 and IIS 7.5. After I make changes in the code and save, I right click and hit View in Browser to see the page. A new tab opens in Chrome and the page comes up fine, but when I go back to the aspx page and make some changes and resave, when I try and refresh the browser tab that opened earlier I get 'This Site Can't be Reached Localhost refused to connect'. I then have to go back to VS and right click and View in Browser again which opens a new tab and the page works. Is there anyway to keep the original tab that opened persistent so I can just refresh it to show code changes? It's a bit tedious having to open a new tab for every change. Thanks.
Edit: seems to be a timeout issue as it doesn't matter if I make changes at all. Trying to refresh the browser after 20 or so seconds causing the connection refused error.
Turns out I have an asp:repeater that builds a table. The table had over 4000 rows in it. When I removed the table or when I reduced the rows to under 300 I was able to refresh the page as many time as I want. As soon as I bumped the rows back up to 4000 the issue came back. Not sure why the amount of data was an issue though.
Go to Tools-Options
Under Projects and solution -> Build
Run select "Always build" under "On Run, when projects are out of date"
I have a customer portal with a few reports in it. When I click a report link on the parent page to view a report, a new window opens (window.open) which contains an ASPX page, containing a reportviewer control.
The report runs (less than 30 seconds):
But then something strange occurs.
If I remain on the parent page, 15 minutes later, the browser is unresponsive. I cannot browse to any other pages on the site, I need to close and reopen the browser to continue. If I do NOT choose a report, 15 minutes later the browser is fine.
I've used network tools to see what the network calls looks like, and all I get is that a call was initiated.. nothing indicating a hung HTTP call, etc. It just.. stops.. If i browse the site immediately after running the report, it's fine! But if I hang out on the parent page after running the report (even after closing the child report window) I get the unresponsiveness.
There is a limited set of compatible browsers, especially on older versions of SQL Server SSRS. I would always recommend IE, which it looks like you are not using?
Here's the compatibility info (for SQL 2016, there's a version selector at the top of the page):
https://msdn.microsoft.com/en-us/library/ms156511.aspx#bkmk_reportviewer
Not really the solution, but finally found a more permanent fix for this. I developed a separate website that hosts my ReportViewerControl. I then developed a web form that loads with a meta refresh, after 3 seconds the page will "refresh" and redirect to my secondary ReportViewerControl website.
Something "goofy" was happening here, the session was getting locked up, almost like the more complex the report, the longer the session was locked up, the more of a chance the browser hanging. Something with the meta refresh and the secondary website causes the session to be completely disconnected (I think???)
There's probably no other person in the world that will have this issue, but if it does, at least others know my story =]