I'm working on an angular application and came across the bug that in Firefox, if we refresh quickly enough (often takes several times) the page will eventually fail to load and, in my case, displays an HTTP 0 error code, which if I'm not mistaken means that an AJAX call was canceled before receiving the response from the server.
I have not seen this behavior in Chrome or IE, but I don't know if that's because the JS engines in those browsers are helping me out, or if it's a browser bug itself (in Chrome at least it appears that the refresh button for a page is disabled while requests are being made on page load).
Is there a Firefox bug, an angular bug, or a bug in my application? If it's the later, how can I avoid this?
Related
I need to implement a feature that checks for changed content before window close and display a predefined warning message if so.
What I did is simply register my handler as follows:
window.addEventListener("beforeunload", checkValueChanged, true);
In the very handler I initiate a synchronous request (using jsf.ajax.request()) to submit all pending data and calculate changes.
The whole solution seems to work pretty well for most cases, but when request takes a little bit longer (300ms?) the browser brutally kills the script without waiting for the response.
It happens only for Chrome (tested on 48.0.2564.116 m) - FF and IE waits for the request to complete. What`s more when I enable developer tools in Chrome it also works.
I suspect that this is an intended Chrome behavior based on a fixed timeout for onbeforeunload handlers execution time designed to protect user from various tricks and hacks on some sites (especially in porno ones :)).
My question is: have you ever encountered and handled somehow such situation? Is this "feature" documented somewhere in Chrome documentation or maybe its a bug? If its a feature can it be locally reconfigured or disabled?
I will be grateful for any hints :)
I've been working on a React JS application with rackt/react-router and testing has recently uncovered an odd behavior specific to IE9.
Context:
We have our F5 set up to perform a protocol redirect (302) so that if someone attempts to navigate to http://react.site.root/#/virtual.page it will redirect them to https://react.site.root/#/virtual.page. Since this is a single page app the redirect is really occurring on http://react.site.root/. This redirect happens as a result of a Keep-Alive request.
Problem:
In IE9 when this protocol redirect occurs the user ends up at https://react.site.root/#/default.route regardless of the virtual page they were attempting to hit. This issue is not seen in later versions of IE, Chrome (desktop or Android), iPhone 5s or 6 (didn't have actual devices to test others). Interestingly enough it also occurs when using any iPhone version in BrowserStack.
My Research:
I have also searched using stackoverflow and Google and the only semi-related issue I found is that IE9 caches redirects, but from what I understand that only applies to 301 redirects and since the protocol redirect path does not include the virtual page or any routing data in the cookies that doesn't seem to fit. Nevertheless I found a test for this that required deleting browser history and running a tab under InPrivate Browsing which indicated this was not the issue. I have also recorded the request and redirect response in Fiddler for both working browsers and IE9 and see nothing suspect.
It seems as though IE9 is treating the redirected page as a new page in the sense that maybe the original javascript context is being destroyed on the redirect, which would explain why react is using the default route. Unfortunately I don't know how to test that theory or move forward with this issue in general. Any help is greatly appreciated.
I found the answer. In short, IE9 and some older browsers forget about the fragment portion of the originally requested URL and will only use fragments present in the redirect response. Since the browser strips the fragment out before making the original request to the server it can't be present in the redirect location.
See the following for more info:
URL Fragment and 302 redirects
http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx
put this at the top of your <head>:
<script>
window.location.hash = window.location.hash
</script>
Problem solved
I have a web app that makes cross-domain Ajax requests. The requests go through without a problem in almost every environment except for iOS devices (iPad, iPhone) running Safari 7. On those devices, the request fails. It works with the latest desktop Safari and also with mobile Safari 5; the problem is only with mobile Safari 7 (and perhaps 6; I don't have access to one of those for testing).
The app first makes a GET request to the origin site (with http protocol), which works fine. It then makes an https POST request to a different site (which is correctly configured for CORS). This is the request that fails. Nothing appears in the Safari console when the request fails and the server logs indicate that no request arrived.
One more detail that may or may not be relevant: the sequence of two requests is triggered by a single user action.
Does anyone have an idea of what's going on here?
EDIT The problem definitely appears to be related to Enyo. I created this fiddle that demonstrates the problem. If you are using Mobile Safari 7 and select enyo.Ajax as the tool for making the request, it will fail. The same request to the same URL will succeed using an XMLHttpRequest object directly. (The server-side script simply echoes the request headers. It also adds
Access-Control-Allow-Origin: *
to the response.)
Looks like this was related to a fix we made for iOS to prevent caching of non-cacheable requests. This fix was updated to only apply to iOS 6 in 2.3.0: https://github.com/enyojs/enyo/commit/73ade2a9dd68deb2f4a4db548c45e2c27104632f
Per the comments in the fix, you can use the header property to specify an object with cache-control: null, unless you're planning on upgrading to 2.3.0. :)
I ran this by the Enyo framework team. No one is exactly sure why you might be having the problem but it could be:
1) This: iOS 7 javascript XMLHttpRequest bug
2) A certificate issue with the https server.
It doesn't appear to be a framework issue, though. If the answer is something else, please let us know!
So I have this problem when I click on someting in a web App which sends an ajax request and then I immediately click on ANOTHER TAB in Firefox (a tab with a completely different webpage) and if I go back to the original my script stopped working and Firebug doesn't show the requests anymore.
Is this a Firebug related problem or do I need to worry about production mode as well?
Does anyone ever have similar?
I heard Firebug used to have problems with other extensions and websites
I want to monitor the client side performance for a page, and I can get the load time of the page by starting a timer in the beginning of the section and also by getting the time of when the onload event happens. However this does not account for the time it takes to request the page from the server. So after searching i've found out that I should use the web timing API. My problem is that while "window.performance" works for chrome, nothing works for firefox including "window.mozPerformance". So does anyone know how I can find the time of when my browser initiates the get request for a page, and finishes receiving the last byte of the page?
You can use something like:
var timing = performance.timing;
var loadtime = timing.loadEventEnd – timing.navigationStart;
This will work for you on:
Chrome 6+, IE9+, Firefox 7+, Android 4+
And you can read more in this old (but good) post:
http://blog.chromium.org/2010/07/do-you-know-how-slow-your-web-page-is.html
Btw, I would use Chrome DevTools (or firebug on Firefox) to measure my code changes in the 'audit' tab. You can see what is the cost for every change in your JS code and measure it without any adding code. Moreover, if you want to see what are the performance of your site (or web app) over time, you have now an option to check the metrics in google analytics.