I'm hoping someone has seen this before because I can't for the life of me find the problem.
I'm trying to do the old "fix the back button" thing in an application and I think i have a pretty decent approach, the problem is that it relies on the application not calling page_load when you hit back and instead loading the cached version of the page.
On about 60% of my pages that's exactly what happens. It loads the cached version and all is well. On the other 40% when i hit the back button page_load calls, forcing a refresh. For reference the call to page_load is NOT in a postback.
Even stranger is that this only occurs in IE (6 & 7). In firefox page_load never gets called.
I am using ASP.NET Ajax framework on both types of pages. Anyone seen anything like this before?
--Update--
After investigating a bit more I'm finding out that when i use the search to navigate from one page to another the application behaves differently for different pages. On the broken pages the page_load gets called twice, the search gets called twice and in fiddler that turns into 2 different redirect postbacks the second of which has no-cache set.
On the working page page_load and search only happen once and it immediately redirects.
That second Response.Redirect is causing the issue. Still not sure why that's happening though.
Check what the server is returning for the cache-control http header, then try setting Response.Cache.SetCacheability()/ use the output cache page directive on the pages and see if the server is saying that the pages should be cached.
if you are using ASP.NET AJAX why not using the History server control object?
replacing History, the back button will go to the link you want.
try this
Related
Ok, so I am working on a custom framework above the .NET framework, and some instructions are not written / called at the good places.
For example, a postback is done on the same page. Then, a Response.redirect occurs right within the page_load; but at this point, the new values of the controls of the page are not yet handled, so they get lost...
Therefore, I wanted to know whether it was possible to force the pagelife_cycle to go forward before the call to response.redirect, so that I can get the right values.
I can't just make that call in another function, because the page I am working on is called by many web applications (about 1-2k), and it would completely change their behaviour, which is not acceptable!
Is that even possible?
See a bit the second image and the Load PostBack Data section. Before the Load event of the page is raised, a textbox is already initialized. You can catch the value by overriding OnPreLoad or by adding a handler at PreLoad event.
I have a requirement to call a save method, that persists a model/object in the session, when the user leaves the page.
The page has various links that do not raise a postback but just perform a redirect. Are there any ASP.Net page life cycle methods I can hook into to perform the save without requiring a postback?
One solution could be to perform an asynchronous POST request (without waiting for a response) when the window is being unloaded:
An example using jQuery:
$(window).unload(function() {
$.post(location.href, $(document.forms[0]).serialize());
});
Although you will probably need to use a slightly different method for Chrome (found on jQuery forums):
It looks like the only way to get the
Ajax request to go through in Chrome
is to use the non-standard event
onbeforeunload. Chrome evidently
doesn't wait long enough to send the
Ajax request using onunload. It does
however wait for alerts...
Well that depends.
If you need to save values when the person leaves the page, then thats kinda hard.
What you can do, is to wrap all your links in some jquery, that says like:
Issue a Ajax Call, to AjaxSave.aspx, then it is completed, then window.location to the links href attribute.
BUT, that will only work if the person clicks on your links, not if the person just closes the browser or something.
You can also take the route to just save the stuff offen, so every time the person issues a post back, you just put the stuff in session. But that will mean that values changed from the last postback to the navigating away from the page is lost - don't know if that is an issue.
The last thing is to do like StackOverflow is doing. If you are editing stuff, it will show a warning when you leave the page, and then you have to click okay, to navigate away from the site.
When I run the web application, I notice that Page_PreRender is fired twice. This only happens the first time in a new session. It does not happen if I refresh the page, or on postbacks.
I use .NET framework 3.5 and the built in ajax functionality.
The problem is not
related to img tag with empty src
attribute (which I have seen other posts with similar problem
has mentioned). I know this because I see this in
both FireFox and IE. The posts I saw
about this stated that this was not a
problem in IE. I have also searched
and found no img tags with empty src
in the generated page source, so it
should not be this.
I have also made a simple test
page where I have included some of
the functionality, and this does not
happen.
Have anyone any suggestions on what happens?
Note:
It is the entire page cycle that is firing twice, not just render.
I've experienced it; it's probably not what you are experiencing, but I'll enter it here anyway; I've noticed it when the application does a Response.Redirect at the PreRender level, which a redirect does not stop current execution, but makes it appear the event happens twice...
Again, probably not related, but including it just in case.
I copied some code that states:
Page.LoadComplete += new EventHandler(Page_PreRender)
I did not realize that this code fire for second time my Page_PreRender event.
When I comment it, never fire twice.
Consider the scenario:
I visited a page of a website built using ASP.NET. The page is a simple aspx page containing ASP.NET server controls.
I clicked on a link which takes me to some other page on the same website.
I clicked the BACK button of the browser.
QUESTION: What happens in terms of page life cycle? Does all the events occur or the browser just displays the cached version of the page without making any requests?
I think the best answer is: It depends on the browser, especially after a post/postback.
Older browsers used to pop up a confirmation dialog to the effect of "the page contains POST data which will be resubmitted", and you could either proceed (resubmit) or cancel out. Since everything that happens in ASP.NET WebForms is part of the FORM element (ViewState, events, etc.), this would cause the entire lifecycle to be repeated.
Of course, this caused no end of trouble with duplicate submissions, so many sites had to come up with workarounds for the dupe problem, and today most browsers just fetch the page from cache instead.
...That is unless you override the cache-control headers and force the browser not to store the page in cache. Obviously, in that case, it can't be retrieved from cache, so it will usually end up being resubmitted. But, again, it depends on the browser - for example, some browsers won't allow the resubmission over SSL, so if that's the protocol in use then the user will just see a message saying that the page has expired / can't be shown.
Come to think of it, probably an even better answer is: As a site designer, you really can't depend on any specific behaviour from the user's browser when the Back button is clicked. If a duplicate submission could have negative side-effects (such as charging a credit card twice), then you need to take adequate measures to prevent that from happening. It's good practice anyway as it's entirely possible for a user to simply double-click the "submit" button by accident.
we have even tried
Response.ExpiresAbsolute = DateTime.Parse("1/1/1980");
Response.AddHeader("cache-control", "no-store, must-revalidate, private");
Response.AddHeader("Pragma", "no-cache");
to resolve this kind of problem
The page would be displayed from Cache.
usually all the events should occur, but if you have an uber browser than it could happen to display a cached page
you can just put a breakpoint in your Page Load and see if it's going to occur
We got strange error last days. ___doPostBack is undefined.
We are building quite advanced website, but not using postbacks much. One of place where postback used is ASP.NET Login Status control.
It is probabalystic, sometimes it is rendered, sometimes - not. For IE, Chrome it works mostly fine, but from FireFox it is quite high chance not to have doPostBack in page source.
Any ideas?
PS: In addition, error happens only on live environment, which uses Windows 2003 & IIS 5.0, dotnet framework is 3.5
Can it be because I am using OutputCache on page level?
Just happened to us: When googlebot or any other bot hits your page before a regular user, the page is cached without any postback options.
We did a simple hack, using different a outputcacheprofile if the request.browser.javascript is false (asp.net sends different versions of the page to those browsers/crawlers/bots)
I had the same problem, but I realized that ASP.NET does not render __doPostback when server controls don't need it.
When I put a gridview or linkbutton that need __doPostback, ASP.NET rendered it.
Yes it might be about the output cache, comment it out and try again please
Usually this happens when you have malformed javascript somewhere on the page (usually, before the __dopostback function).
Have you viewed the page source and looked to see if the __dopostback function is actually rendered in the page, regardless of whether you're getting the error or not?