I'm working on some old AJAX code, written in the dark dark days before jQuery. Strangely, it has been working fine for years, until today when it suddenly stopped firing its callback. Here's the basic code:
var xml = new XMLHttpRequest(); // only needs to support Firefox
xml.open("GET", myRequestURL, true);
xml.onreadystatechange = function() { alert ('test'); };
xml.send(null);
Checking the Firebug console, the request is being sent with no worries, and it is receiving the correct XML from the request URL, but the onreadystatechange function is not working at all. There's no javascript errors or anything else strange happening in the system.
I wish I could just rewrite everything using jQuery, but I don't have the time right now. What could possibly be causing this problem??
A further update - I've been able to test my code in a different browser (FFx 3.0) and it was working there, so it must be a problem with my browser. I'm running Firefox 3.5b4 on Vista, and I've tried it now with all my addons disabled with no luck. It's still really bugging me because I was working on this site yesterday (with the same browser setup) and there were no problems at all...
Actually I just took a look back in my Addons window and saw that Firebug was still enabled. If I disable Firebug, it works perfectly. If I enable it, it's broken. Firebug version 1.40.a31
is the url malformed?
have you tried putting the whole thing in a try-catch and alerting the errors (if any)
is it failing on an authorization check?
does the url in question require http-auth? (though there should be state changes in this case, I'll admit)
edit:
I have a really funny thought here. Are you using firefox 3.5 beta4? I develop a firefox extension for a browser-based game and recently discovered some odd behvaviour. With my extension or firebug observing the ajax requests made from the page, the script ccreating them would never get calledback. The request would be correctly observed and processed by both firebug and my extension (I could observe what was sent and received)... but the page itself would never hear from the request again -- like it had disappeared into a black hole.
Try turning off firebug (or at least turn off listening to 'Net' for that domain) and test it again
Known Firefox bug affecting Firebug; see http://code.google.com/p/fbug/issues/detail?id=1569&q=xhr&colspec=ID%20Type%20Status%20Owner%20Test%20Summary for details :-)
It seems unlikely that onreadystatechange would stop working. Is it possible that the 'alert' function has somehow been disabled or overridden? Can you replace the alert with some code to make a visible change in the page, and check its functionality that way? (I know, its a stretch, but it just seems so strange that onreadystatechange wouldn't work!)
Related
Just a bit of background - I was updating a legacy feature that is all javascript as there was new functionality being added to our web app that the legacy feature had to interact with.
While testing this update we noticed that there was an issue when moving from page to page within the web app - the legacy feature is supposed to follow you if it has been activated.
Basically the data from the activated feature wasn't being retained. There is some code in there that was supposed to do this. After some investigation it was discovered that it is working as expected in IE/Edge and Firefox but the exit code is not getting executed in Google Chrome and Safari.
This might explain why the business wasn't aware of the issue but it's been confirmed that the issue is also in the live site so hasn't been recently introduced as I believe most of the users would be on IE.
The code that was managing the exit functionality was as follows:
if(window.onpagehide || window.onpagehide === null){
window.addEventListener("pagehide", storeDataFunction, false);
} else {
window.addEventListener("unload", storeDataFunction, false);
}
With the above code the logic within the storeDataFunction doesn't even execute when you attempt to leave the page.
After some browsing on here and other forums I have updated the above to:
window.onbeforeunload = storeDataFunction;
and made storeDataFunction return null.
This appears to be slightly better in that the storeDataFunction is getting executed when moving pages but deep within it there is an ajax POST to a controller in our web app that stores the data necessary to check if the feature is active and what it has done and this ajax request does not get executed.
Again this is only on Chrome and Safari and works fine on IE and Firefox.
So what I'm looking for is a steer. Am I heading down the wrong path using onbeforeunload for what we want to achieve here? Or was the original use of pagehide/unload more appropriate?
Are both of those incorrect and there is a better way of doing it?
This feature was developed about 7 years ago so I'm not even sure if it ever worked on Chrome or if it did at time of development and some more recent updates in Chrome changed they way it handles page termination.
Thanks in advance.
Looks like Google have updated Chrome to stop XHR during page dismissal.
https://www.chromestatus.com/feature/4664843055398912
Okey!
So I am running a Spring MVC Thymeleaf project. I have a simple alert which should show each time when I start my site. This works perfectly except for when I try it with Explorer (IE11). Tried on Chrome, Edge, Firefox.
Its a very simple "alert ("hello")" in document.ready
I tried to "allow javascript" on internet explorer. It still doesnt work, i tried if javascript is allowed by going to different sites.
Hmmm what more could be more relevant.
I tried to ad localhost to "trusted" sites, doesnt work.
I tried the code on jfiddle and sites like this, works a treat.
I have localhost so the site is not "secure" obv, this is not the problem because I have tried the code on the host aswel. I have googled and tried but I cant do more than I've done... Nothing seems to work.
Anyone out there with the same problem? Thanks.
You can try by checking following.
Ensure your console doesn't show any errors and correct them if there are any.
Be sure you didn't disable browser prompts on IE
Try using window.alert() - it's possible (though improbable) that another alert() is conflicting with window's.
If you have console support, try console.log(alert); and see what it says. It should be something like:
function alert() {
[native code]
}
I have browsed the web trying to find a solution to this problem, many people have suggested disabling avast plugin, add blocker within chrome extensions yet none of these worked.
the url is https://careers.telstra.com/ you will see half way down next to the facebook feed the twitter feed is empty when using chrome, when I view this in IE, FireFox it displays as I would expect.
I've checked the console log in Firefox and I receive no errors, when I go to chrome on the other hand I see the following:
I personally do not think these are related it any way but I thought I would provide as much information as possible to try and get this fixed.
update Turns out the errors are related to google-cast-sdk instead of silently dumping the errors they have decided to dump them straight in to the console. Read more about it here
I've checked and made sure I'm referencing the correct twitter widget.
We build it as follows as pass it to the page
sb.Append("<div class=\"twitterWidget\"><a class=\"twitter-timeline\" href=\"//twitter.com/telstracareers\" data-widget-id=\"345026269295038465\" data-chrome=\"nofooter noscrollbar transparent\" data-tweet-limit=\"3\">Tweets by #telstracareers</a></div>");
The website runs under https, I have tried the following:
href=\"https://twitter.com/telstracareers\"
href=\"//twitter.com/telstracareers\"
Still have no luck, I'm not sure what else I could try any suggestions?
Thanks
FF25.0, Fedora 18.
This just keeps going round in circles. The staging extension installs, and parts of it are active as the extension modifies a bit of the dom (I think even the background script is running too as the local storage is initialized). Not all of the extension works, such as the sidebar and other dom injection that should run on page load. But the debug mode page in crossrider fails to recognise the running extension.
I suspect this is due to a bug in my code but there appears to be no way to debug it. When I commented out the sidebar, it still showed briefly after another install, which makes me suspect a proxy/cache is getting in the way but adding an extra GET argument on the extension URL didn't help. I've tried adding debugger to extension.js. The console is empty. No errors are reported by firebug. The extension works fine in chrome, and I really don't want to go back to a blank extension and try adding bit by bit till it fails. There must be a simpler way such as making firefox just say, "here's your problem, right on line number X". Any ideas?
[EDIT]
After turning on some debug options, I've got errors in the console, but clicking on the offending file/line number just opens the "Source of:..." window. In google chrome I get the file in the debugger, can hit break points, refresh and catch the error as it happens. Better yet, how about a "break-on-exceptions" option that both works but also actually works.
[EDIT]
I finally got the Browser Debugger working. The first error is a NS_ERROR_XPC_BAD_OP_ON_WN_PROTO.
Well, to start actually getting messages you need to set some flags in "about:config" listed here: Setting_up_extension_development_environment
I'll copy a few...
javascript.options.showInConsole = true (this was already on for me)
browser.dom.window.dump.enabled = true
javascript.options.strict = true (there's also a debug version I turned on too)
devtools.chrome.enabled = true (nothing to do with google chrome)
devtools.debugger.remote-enabled = true (the important one, allowing Firefox->Web Developer->Browser Debugger, make sure to allow the remote debugger otherwise it undoes the config change)
devtools.errorconsole.enabled = true
extensions.logging.enabled = true
It looks like quite a few options have been removed too. This has at least got me started.
[EDIT]
This answer also mentions the "Web Developer->Browser Debugger" (which is currently blank - "no sources" - I have no idea) and "Web Developer->Browser Console" windows (just seems to have the same output as the in-window console).
Throw a giant try/catch around ALL your extension code. At least this allows the crossrider "staging" extension to install and be recognised.
Print the exception (I assume all the stupid about:config stuff has to be set for this to work)
appAPI.ready(function($) {
try {
...rest of extension code
}
catch (e)
{
console.log("#################", e);
}
}
Locate the error in the console, and click on the [object exception]. Note the line number (it won't be correct as other code is injected). Also note we've managed to print an exception and firefox failed to break on it. FFFFFFFFFFFFFFFFFFFF
Add some newlines approximately in the middle of the code.
Reload. Note the line number. If it's changed the error is after the newlines. If not the error is before.
Repeat from step 4 until the error is found.
Take a moment to reflect on the stupidity of this process. (this isn't exactly a comment directed at crossrider, more at the severe lack of simple web development tools and APIs currently available)
I'm using IE9 to debug a web app. I made some changes to the javascript after loading the page. I'm not able to get IE9 to stop on the new code. The message is "The code in the document is not loaded". I can set breakpoints when I'm not debugging, but they won't be valid when I start debugging. I'm using IE7 Browswer Mode, IE7 Document Mode.
Things I've tried:
close dev tools window, re-open
stop debugging, start debugging
Ctrl R in dev tools window (same as Clear Browser Cache button)
Ctrl R on the IE9 web page
Ctrl F5 on the Ie9 web page
Clear browser cache for this domain
Check (set) Always refresh cache from server
Next thing to try (I guess) would be closing IE completely. Is that the fix for this? If so, yuck. It takes me a couple of minutes to set the page up so doing that after every JS change really stinks. I can use FF4 to develop the JS, but the JS issue I'm seeing is specific to IE7 so I have to do it this way.
>> How can I get IE9 (running in IE7 mode) to reliably debug the most current JS from the server?
This issue wasn't related to caching etc. IE9 was hitting a script error (missing closing paren) in the new code and not allowing breakpoints anywhere in the script. IE seemed very quiet about the script error though. Anyway, fixing the script error fixed the issues with breakpoints / caching.
If you have access to the code:
In you javascript file reference add a query string, something like this:
<script src="Scripts/main.js?v=1" type="text/javascript"></script>
And every time you change in the js file change the v value to something else, like that the browser will feel that this is a new file and will get it.
Add this:
window.applicationCache.addEventListener('updateready', function (e)
{
if (window.applicationCache.status == window.applicationCache.UPDATEREADY)
{
window.applicationCache.swapCache();
if (confirm('A new version of this site is available. Load it?'))
window.location.reload();
}
}, false);
I found this solution somwhere in the Net. Sorry, but I don't remember the author. It works for me when I debug Web App with JavaScript in Visual Studio and use IE.
I found this question based on the "the code in the document is not loaded" error message. I'm not using IE7 document mode or any of that, just IE9.
Like jcollum, my issue wasn't related to caching.
I'm using MVC.Net, and someone had set up a piece of javascript to rely on a string in the ViewBag. I changed a couple things, and that ViewBag string disappeared, so the resulting javascript looked something like this:
if(!()) {
// Some code
}
Javascript died right here, and wouldn't process the rest of the code in the block. This was confusing, as it was still trying to execute javascript in a different set of script tags, but which relied on a variable set in the other block it wouldn't load.
So, basically, a syntax error was introduced via strange means, and the debugger refused to load some of the code which came after it. Another lesson on the dangers of ViewBag.