I wanted to understand why does the IE11 respond with a long running script issue and becomes unresponsive till some time.
Surprisingly, this happens randomly
eg. Let's say on page load I call an API which responds with a bookings.
CASE 1: When number of bookings are less than 10 , it works perfectly FINE....
CASE 2: When number of bookings are more than 10 , it encounters this long running script issue
As per the suggested fixes for this issue I see only IE11 Browser browser configuration /system settings changes only Eg: https://appuals.com/long-running-script-ie11/ which can't be triggered on customer side.
Would be thankful if anyone provides some clarity on this issue and possible fixes apart from config changes!!
Related
We are using Marty.js (and React.js) in our webapp.
As I read in the Marty.js docs they're using the fetch-polyfill to communicate with the server over http. Everything fine so far ...
While testing in Google Chrome (currently v42) first I noticed that the body of the request isn't shown (but sent ?!?) and then that I can't "replay XHR" from the dev-tools.
Can anybody tell me why this is the case?
update 04/26/15
Because it seems to not have anything to do with marty.js I removed it from the question's title.
I believe what you're seeing is related to two issues in MartyJS' github.
https://github.com/martyjs/marty/issues/308 (success function called regardless off http status code returned)
https://github.com/martyjs/marty/issues/293 (martyjs not deserialzing json properly in certain browser setups) <-- this is the one you're having a specific issue with it looks like.
There was an update to the library to fix both of these. I recommend upgrading. We haven't had any problems since grabbing the latest as of a week ago (0.9.14). I believe a new version has already been released (0.9.15) while work on 0.10 is being done in parallel.
We have a big single page application, that started to crash from time to time. We were trying to debug it for a while now, but unfortunately, still no results. We used traditional debugging tools, but they were not very useful - perhaps not used correctly.
The app seems to crash most often on Safari, it doesn't crash that often in Chrome, but it still does, so I can't rule out a problem with browser(s).
I have managed to get this crash report, which you can find at the end of this question, unfortunately I don't know what to look for in it. I know it's huge and I'm just throwing it at you saying "here, find a bug", but could you possibly have a look at it and give me some hint what might be wrong or what should I focus on in the report?
Here is the crash report http://pastebin.com/bNxpuS6T
Thanks
What I can see from the crash report and the source code is that your JavaScript code was trying to destroy some DOM objects while still iterating through those, which is the reason of the crash.
I guess you may want to check if any timer associated with the idle tabs is still active.
DETAILS:
The WebKit crashed at
1 com.apple.WebCore 0x00007fff83cace2d WebCore::ScriptExecutionContext::willDestroyActiveDOMObject(WebCore::ActiveDOMObject*) + 45
where the source code is (click here)
void ScriptExecutionContext::willDestroyActiveDOMObject(ActiveDOMObject* object)
{
ASSERT(object);
if (m_iteratingActiveDOMObjects)
CRASH();
m_activeDOMObjects.remove(object);
}
As part of a loading screen for an offline-enabled web application I'm building (using a cache manifest), I'd like to display an accurate progress bar that lets users know which files has thus far been downloaded and which are still pending. Something like the following:
Loading...
/assets/images/logo.png: loaded
/assets/images/splashImage.png: pending
I know that I can use the cache "pending" event, but I don't see that the event arguments have any data associated with them.
Is there any way to do this?
There is a progress event that gets triggered when each file downloads, however its payload does not include the file name in any browser that I've tested with (Chrome, Safari, FF beta). Chrome displays the file name in the Console (though as far as I know it's inaccessible to JS), but neither Safari nor FF even go that far. And from what I've seen, the files do not download in the same order that they're listed in the manifest, so there's not even a way to generate an ordered list then knock them off one at a time.
So in answer to your question, no, there isn't any way to do this right now. It's possible that in the future the progress event will include the filename - at least in some browsers - but right now this isn't possible.
I should add that in Chrome (not in Safari or FF) you can at least get a count of files to be downloaded, allowing you to at least calculate an accurate progress bar. To get this in Chrome you'd use the following:
function downloadProgress(e) {
totalfiles = Number(e.total);
}
window.applicationCache.addEventListener("progress", downloadProgress, false);
However this will error out in other browsers, so you need to wrap a try/catch or some other method (typeof(e.total)) to avoid the error.
This is a few years late, but maybe it'll help someone else who's researching this.
It doesn't list the files or anything, but it shows an accurate(ish) progress bar based on the total number of files loaded. It may still need a little work...
https://github.com/joelabeyta/app-cache-percent-bar
I have a bit of a strange problem. For one of my clients I've added some ajax functionality to their website. To get the context; it's a website for a travelagency and pricetables are generates by ajax-calls to reduce serverload and improve user experience.
Only now I received an email where they say it is not working in IE7. So, to test this I first installed IETester but this almost crashes every single time I only open a website. So I've downloaded a trialversion VMWare Workstation and installed a virtual XP machine with IE7 (because IE8 is on my primary Win7 install). What a hassle to simulate an error eh?! ;)
Anyway. After some debugging I think it's the xmlHttpRequest status property, when I try to alert this status in the corresponding javascript function IE shows an exclamationsign at the leftbottom corner with some vague 'not further defined error' message while in IE8, FireFox and Chrome this is no problem at all.
So I figured I might have been using the wrong XMLHttpRequest object. But then again, the first call which is also made to intiate the first pricetable for the closest month works just fine. Just to be sure I googled which object should work for IE7, now I'm using Msxml2.XMLHTTP and the initial load goes well.
When I click an <a onclick="callToFunction(with, correct, params)">click</a> it gets into the function to update a <div> but then it sort of freezes. I found out that the xmlHttp.readyState is 4 but I can't output the xmlHttp.status, then the 'not further defined error' message shows again at the leftbottom corner.
My question after a bit of a long evening trying to solve this, do you guys have any clue what might be the problem?
Example:
http://www.bergenmeer.nl/50/oostenrijk/tirol/gerlos/residence-zillertal.html
Click tab 'Prijzen en aanbiedingen' (Prices and special offers) then click another month in the bar below, e.g. jan, feb, maa.
Note, the disfunctioning only appears in IE7.
In IE7 you could try using native window.XMLHttpRequest.
For what it's worth, I once had an issue which was resolved by removing xmlhttp.setRequestHeader("Connection", "close"); (which I did not see in your code...)
We recently started using SVN Keywords to automatically append the current revision number to all our <script src="..."> includes (so it looks like this: <script language="javascript" src="some/javascript.js?v=$Revision: 1234 $"> </script>). This way each time we push a new copy of the code to production, user caches won't cause users to still be using old script revisions.
It works great, except for IE6. For some reason, IE6 sporadically acts as though some of those files didn't exist. We may get weird error statements like "Unterminated String Literal on line 1234," but if you try to attach a debugger process to it, it won't halt on this line (if you say "Yes" to the debugger prompt, nothing happens, and page execution continues). A log entry for it shows up in IIS logs, indicating the user is definitely receiving the file (status code 200, with the appropriate amount of bytes transferred).
It also only seems to happen when the pages are served over https, not over standard http. To further compound things, it doesn't necessarily happen all the time; you might refresh a page 5 times and everything works, then you might refresh it 20 more times and it fails every time. For most users it seems to always work or else to always fail. It is even unpredictable when you have multiple users in a corporate environment whose security and cache settings are forcibly identical.
Any thoughts or suggestions would be greatly appreciated, this has been driving me crazy for weeks.
Check your log with fiddler2 to make sure the browser request the page, and do not use the cache instead. Also check the URL of the JS script and the header returned.
Are you using GZip? There has been issues reported with it.
I would suggest testing using Internet Explorer Application Compatibility VPC Image. That way, you can do your tests with a 100% IE6, and not one of those plugin that claims to simulate IE6 inside another browser.
I think this is a very clever idea. However, I think the issue could be related to the spaces in the url. Technically, the url should have the spaces encoded.
See if you can customize the keywords in SVN to generate a revision number without special characters.