I've encountered a strange bug in Chrome 19. I implemented a full-AJAX website (every non-external link is opened via AJAX request) with pushState support. I transmit the HTML snippets in AJAX via JSON format.
When I leave my site via an external link and then go back, Chrome renders cached data for that URL - the problem is, he caches the JSON content and shows that, instead of full web-page.
This is reproducible by these steps (UPDATE: I removed AJAX functionality on my website since then, so this bug does no longer appear):
Open http://beta.mirtes.cz/
Click on the second date link (16. 6. 2012 next to "It all began with a strange e-mail"). This page (you are now at http://beta.mirtes.cz/it-all-began-with-a-strange-e-mail) is loaded via AJAX.
Click on "It all began with a strange e-mail". You are redirected to an external website.
Click "Back" in Chrome after the page is completely loaded.
I try to send all AJAX responses with Cache-Control: no-cache, but with no effect.
Firefox 12 works OK.
I came with a workaround - I perform AJAX request with additional dummy GET parameter - ?ajax=1. This way the browser can recognize the difference between usual HTML content and JSON. It doesn't have any impact on the user, the parameter is visible only in Firebug.
Related
The question is probably easily misunderstood, so I'll go into more detail:
I am trying to automate a task in a certain (very outdated) browser-based idle game that is written in PHP in order to polish my portfolio with a little more variated projects.
I used DevTools to reverse most of the requests and wrote a small C# Request wrapper to test them. I can get most of the actions I want to work, using the respective ajax get requests and the correct cookies/headers - not really part of the problem.
Example:
Attacking an enemy:
https://somebrowsergame.com/game/ajax.php?mod=location&submod=attack&location=3&stage=2&premium=0&sh=****mysessionhash****
Making a GET request to this URI with the correct headers and cookies, I can perform the in-game action programmatically and successfully from my C# console application and see that the fight has taken place when visiting the site in the browser.
The problem:
When monitoring all requests after clicking the "attack" button, via DevTools, even with preserve logs enabled, I don't see any redirects or way of determining how my browser gets told where to navigate to.
Findings
I found out that the button calls a javascript function attack() in its onClick event and tried debugging the javascript in DevTools in order to find out where somethign happens (such as setting document.href or smth), but when Debugging I ran into a seemingly infinite loop of setInterval handler and setTimeout handler in the call stack.
I also cleared the Network tab after the onClick event (and after the ajax request which I could find during Debugging) but the only request/response I got was the document GET request for the final page, no request telling my browser which site to navigate to.
Monitoring requests
The request made to initiate the action (via button click on website or ajax GET request as outlined above)
The document response / site navigated to
What I want to know is how my browser got told which site to navigate too, as the request URI for the document request (getting the html of the target page) has a parameter generated on the server side (logId)
I have also used "All" request types in DevTools, as well as negative filters when monitoring requests but never was I able to see how my browser knows which page to navigate to. I tried with source breakpoints at "beforeunload", tried inspecting the javascript source connected to the onclick event of the button (which didnt give me anything, as the js is minified and barely readable - i am not even sure if the navigation is done via window.target.href) and googled this question in all possible wordings which lead me nowhere
I am not too versed in web development, but I am sure my browser has to be told where to navigate to in some fashion after clicking that button?
My web app runs under Tomcat, it uses AJAX requests very intensively, and during the development process I have to redeploy the web app intensively too. After the redeployment I usually simply refresh the page knowing that the user session is dropped, but I always get to the scenario described below:
Go to some page, a really big page with many JS-scripts included, that actually makes those intensive AJAX requests.
Stop Tomcat or redeploy the web app.
Refresh the page.
Enter the credentials in the sign-in form to authenticate.
Suddenly get the last AJAX request response in the browser window and the AJAX request URL in the URL bar.
Wow... It looks strange for me that AJAX request URLs appear in the URL bar along with their response in the web page display area. This actually happens to Firefox and Chrome (haven't tested it in other browsers). Unfortunately, I cannot reproduce the same behavior in a simple page written from scratch. Frankly speaking, I don't really understand what happens to such requests and why do browsers "think" if AJAX requests/responses are entered in URL bar by user...
Your possible explanations or hints for such a strange behavior are very and very appreciated. Thanks!
(Perhaps it can help: All AJAX requests are performed with jQuery 1.4.2)
I'm very sorry, as I understood later, the question is not complete, because there was another pitfall I didn't mention, so no one couldn't answer the question in principle. The reason of the bug was hiding in the... <body onunload="..."> tag definition. That was quite unexpected, but that code contained some AJAX request that must be invoked when a user leaves the page. I only realized that the authenicating module (FORM, j_security_check) returned a response (HTTP 302) containing the Location header - so that was the reason why browsers did redirects.
The exact scenario was like that:
Open the page containing <body onunload="some_ajax_here">.
Log out the app using another tab so you could stay at the same page.
Refresh the page so some ajax could be invoked - this AJAX request is not now allowed because it's a secured part of the application (you get the forwarded content of the login page).
Enter the credentials and now oops you get to the result of some ajax directly in the browser window.
As the quick fix, and I hope the final one, I added another request following that AJAX request:
$.ajax({
async: true,
method: "GET",
url: document.location.pathname + document.location.search
});
So the HTML page script simply makes self-page request the last one - j_security_check returns the Location referring the last used HTML page, and the redirect works fine. Perhaps my explanation is not clear and may be not complete or even full of mistakes, but it looks like that in general. I'm very sorry once again, and thank you #ChristopherSchultz!
If using the current Chrome, Firefox, and Safari, when switching between
http://www.facebook.com/my_name
http://www.facebook.com
The side panel for feed and chat, and any chat box actually stays. I thought when the URL changes, the page has to refresh as a whole, but obviously, this is not the case here. How is that done?
On IE 9, the URL actually became http://www.facebook.com/#! and using the "hash" to do ajax without refreshing the page, which is more understandable.
You can change the URL and page history from javascript without actually reloading the page.
See this answer on another question.
Note, that if you type the new URL by yourself and press enter the whole page reloads.
this might be the internal linking in the webpage with hidden DIVs with IDs and onClick those Hidden DIVs get visible with javascript and with AJAX content is loaded it will be a good if you browse the site disabling javascipt
I've search high and low for an answer to this but unfortunately I'm stuck. The problem is only occuring in Firefox (tested IE, Chrome and Safari also - works fine, no errors of any sort). I'll detail the sequence of events to save posting all my code.
ASP.NET MVC 3 application, basic form loads into a jQuery UI dialog
Custom jQuery to hijax the form submit (serialize the form and then $.post to the server - no compiler errors when debugging and post shows up in Firebug without errors)
Http GET (automatically happens) getting the response object from the server (+ success text and XHR), response is plain HTML in this case (again, shows up in Firebug with no errors)
Custom jQuery to change the HTML of the UI dialog from it's current HTML to the response Html - this is where it fails.
I've used javascript alerts to debug the sequence of events and as soon as the post (and get) is complete, everything just... sort of stops.
As I say, only in firefox! Very odd, just wondering if there's any known bugs with ajax and firefox or anybody has heard of a similar situation?
I must also add, that on other parts of my site, this works perfectly in all browsers! The only difference between this form and the other forms that do successfully complete the function is that the response from this form is the same "page" again but updated rather than a new "page". (I use "page" as I got all this working with Javascript turned off first and for graceful degredation)
HELP! Or laugh, either is fine.
UPDATE
I have tried sending a view with a blank model back as the action result - works in every browser except firefox - firefox retains the values from the previous post! And then I got to thinking - that's a trait of firefox isn't it? And maybe that's why the original "re-direct" html response doesn't work?? I think it's time to give up and let people know they can't use Firefox for that particular function!
Ok so I'm answering my own question.
The only way I found to get round it is to use $.ajax instead of $.post and to use the option async : false
Hope this helps somebody.
Rob
Have you tried adding the attribute [OutputCache(Location = System.Web.UI.OutputCacheLocation.None)] to your Action for your GET? It sounds to me like a caching issue.
I have a page that gathers environment status from a couple of IBM WebSphere servers using iframes similar to this:
<iframe src="http://server:9060/ibm/console/status?text=true&type=server&node=NODE&name=ServerName_server_NODE"></iframe>
and it happily prints out "Started" or "Unavailable" etc. But if I load the same url in a normal browser sometimes it works, sometimes it does not? Some of them are showing a login page, while others are simply return HTTP code 500.
So whats the difference between loading the page through an iframe vs through a browser?
I can tell you that the iframe solution works no matter which machine I am doing it on, so I do not belive it has anything to do with the user whos opening the page. And before you ask, why not keep the solution that works, well its because it takes a long time to open the page with the iframes vs a page where everything is requested through ajax.
Update: Using jQuery to perform the ajax call returns "error" and "undefined" for the servers that I can't see in a normal browser.
One difference is an iframe has to render the view while XHR would not.
An iframe is essentially the same as opening with the browser. In both cases the browsers credentials are used, so there will be no difference between the two.
Secondly, loading something in an iframe should take the same amount of time as requesting it through XHR, since in both cases the browser makes an HTTP request and waits for the response. Although I should add that an iframe will take time to render the content onto the page. However if you plan on displaying it with ajax anyways, an iframe/xhr solution will be more or less the same.
In case of ajax request same origin policy (which restricts cross domain call) comes into picture. So you can't make cross domain call using xhr. Alternative for same is embed flex swf file in your page as activex control and make flex call through javascript and then flex is responsible to make cross domain call (flex can if targeted domain allows cross domain using crossdomain.xml) and renders result using javascript again.