All over my application, buttons, link buttons and image buttons seem to become disabled. A few refreshes of the page, or a reload, or sometimes it requires a restart of my browser (This occurs in all browser) will re-enable the button. I haven't got a clue how this is happening and it is driving me, and my clients nuts. I am assuming it must be something to do with the page lifecycle but can't understand why the issue is intermittent.
Has anyone come across this before?
Look at all the intial states of your buttons in the .aspx page. See if it's all consistent as far as their Visible and Enabled properties.
Then identify any code in your code-behinds or javascript that would modify those properties. (I always have a Sub called 'SetFormAttributes' in my maintenance pages)
Look for things that might inconsistently cause postbacks that you might not be seeing.
The key to finding this is to understanding everything that is or COULD be going on in that page.
Related
What happens to the visual elements on a contentpage, in a shell-application, when you navigate to another page?
The specific pages, seem to remain alive, judging by the constructors only being called on first display and not when subsequently navigating back to the page again, but it seems that some/all the visual elements on a contentpage are refreshed when navigating back to the page.
This is specifically something I see when placing a forms.map or syncfusion.sfmap on a page, and navigating away from the page and then back. The maps obviously reset to initial values, on reload, so they are apparently killed off and recreated. Making a custom renderer for a map shows OnElementChanged being called on reloading, also indicating that it was not "just kept on hand" for when the page would reload.
It seems that the forms classes, encapsulating the deeper controls, do persist, but they disconnect from the lower level controls, and reloads them when becoming visible again? I am somewhat new to mobile development, and may or may not miss the entire point here...
The real question is if I can avoid that behavior. I have a shell app with various pages containing maps. Those maps are populated with various graphics objects and are being panned and zoomed, so it is a real pain to have them reset when briefly moving away from a page. Is there a way to avoid that, so they just quickly pop back to life when the page is displayed again?
We have analyzed the query and we would like to inform that not only Maps controls, simple ContentPage also act like this. It destructs the old pages and re-creates the pages view while come back in navigation.
I'm making a webpage in ASP.net, combined with VB.net. The current page I'm working on, is some sort of 'Quiz' webpage. The user has to fill in 40+ radiobuttons, depending on his personality and such.
Though throughout testing I've realized the webpage will occasionally reload, forcing every checked radiobutton to go back to unchecked. This will happen at seemingly random moments, sometimes not at all, sometimes 2 times in a row. This is especially annoying since there are so many radiobuttons to be checked, forcing the user to start over.
Does anybody have any idea why this could happen? Any help would be much appreciated.
if(!Page.IsPostback)
{
//.. your code goes here
}
In an ASP.NET 3.5 website we are noticing that the back button is not working properly. If the user does several postbacks (say 10 times), and than starts pressing back button - the back button gets disabled before the user gets through all the pages. The site does not use AJAX.net.
I can reproduce the issue on IE 7 and 8 almost always. The problem seems to be with some sort of limit IE has on History Cache for a given tab/instance. In the tests I did the post request to the server are large - around 83k, and the responses are are round 300k. It seems that with these request sizes the history does not hold more than 4 items. The moment I get to the 5 post, the first item i had selected is dropped.
We experienced the same issue. We would load a particular page, and after about 5 seconds, IE8 browser history would get blown away. As a result, history.back() would not work, and IE8 back button would not work. Eventually, we narrowed it down to the large "viewstate" (In our case, the size of the "viewstate" was like 600KB due to "Repeater" control having "viewstate" enabled). When we disabled the "viewstate" on the "Repeater" control, the size came down to about 11KB. Now, both IE8 back button and history.back() work well.
The user has to have gone back to the first page; that's the only way I know of to disable the back button in IE (or any other browser). Did the application open another tab; that could cause confusion on how far the back button will go.
Also, is the user getting prompted, by IE, to reapply changes when they hit the back button? I know that is an issue with ASP.NET sites in general and that could cause problems in the browser with using the back button.
window.location.replace
or
history.forward();
in the head
This is a bug in IE that has manifested in one way or another since (at least) IE6. The bug is in the TravelLog code. It sometimes gets confused.
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 have an ASP.NET application that we recently migrated onto a new server with IIS7 and .NET 3.5.
In this new environment, some users that are on IE (6, 7, or 8) are experiencing bizarre intermittent problems with postback not working on ASP.NET buttons. (you click the button and nothing happens)
The issue happens sporadically. Sometimes it works, sometimes it doesn't. For some users the button postback almost never works (but sometimes yes!). To complicate matters there are some pages with asp.net button postbacks that DO always work.
Other pages contain a mix of 'asp buttons' and 'asp link buttons', in which the asp button postbacks often don't work, but the link button postbacks always work.
Javascript is enabled and works. The source DOES contain valid tags.
I actually managed to take View Source snapshots of the same page when it was working and when it was not working and the source was EXACTLY the same!!!
At first I thought it was a problem with IE6, but it's now been reproduced on IE7 on one user's machine.
How would I even BEGIN to tackle this problem?
Any help, ideas, or guidance would be vastly appreciated. I am at the end of my mental rope here.
I know this topic is pretty old, but I found the same problem in my code.
I am using the ComponentArt component library.
In certain circumstances after a postback, buttons with codebehind will no longer execute in IE. I also noticed that buttons with onClientSide clicks would execute their postback when the JS function completes and returns true.
I was able to get all the buttons on the page to submit by adding the following code to my buttons:
OnClientClick="javascript:return true"
Any buttons that are already running a JS function and returning true, should work without issue.
See if this post helps? IE 6 treats buttons a little differently, especially if you have some name conflicts. I could see this being a problem for events if that is the case.
Found the culprit.
It was ComponentArt's 2007 Web.UI components that were being dropped on the page.
Apparently the menu control mixed with the 3.5 framework causes wierd issues with postback not working.