We're getting a confusing error on two of our pages in our ASP.NET application. Both pages originaly had tags to reload the page every so often if a user sat on it for a while, but opted to remove those in favor of some AJAX flavoring. Specifically, we created timer controls on the page and wired the timer's tick event as a trigger for an update panel to reload a portion of the page. The page(s) also have scriptmanagers on them as we don't have one on the master page. This largely works great except we're getting a lot of these errors:
"The page is performing an async postback but the ScriptManager.SupportsPartialRendering property is set to false."
It is my understanding that if the .NET framework detects a browser doesn't support partial rendering it will set the ScriptManager.SupportsPartialRendering value to false and we're NOT overriding this in any fashion. Therefore, the pages shouldn't be by performing async postbacks if that value is false, but based on the error the postbacks are still happening and the page is throwing an exception.
Curiously, the user agent always seems to be GoogleBot or "Mozilla/4.0 (Windows 98; US) Opera 10.00 [en]".
I'd apperciate some insight. We've toyed with the idea of forcing the SupportsPartialRendering to true, but that doesn't explain why ASYNC postbacks are even occuring if the .NET framework is setting this to false based on the the browser caps.
I'm finding this, too. It appears that newer browsers will also cause this exception. The items that I've found so far -- though I've not resolved my own scenario -- are as follows:
Ensure the <xhtmlConformance mode="Legacy" /> is not set to Legacy
Potentially by removing Hidden fields
You can disable partial rendering entirely by setting ScriptManager.EnablePartialRendering to false. This will force an update panel to reload the entire contents of the panel at once.
I find SupportsPartialRendering confusing as well because of the name and because it is doing two things.
It acts as a flag to determine if the browser supports partial-page rendering. As a flag, it won't actually prevent asynchronous postbacks, that's why you get the error still.
You can use it as an override. You can allow asynchronous postbacks regardless of what the browser is, but you can't prevent it with this property.
Cheers.
Related
I'm storing a few of my properties in the viewstate, so I can use them easily on Ajax requests. My property code looks like this:
public Language Language
{
get { return (Language)ViewState["controls_window_Language"]; }
set { ViewState["controls_window_Language"] = value; }
}
However, my customers have reported some errors, and when I've tracked it down, it's because Language is null. It doesn't happen every time; it appears to be totally random, and I can't reproduce the error. I'm also storing other properties inside the viewstate, and I'm using that property just before Language, so I havn't lost all viewstate.
Most logical reason would be that Language is overwritten, but the only time I write to it is when the page is first loaded.
What can be the reason for losing my viewstate property?
I'm not sure if this is the issue, but using the back/forward navigation in the browser can often cause unexpected results, especially on pages using a lot of asynchronous calls.
Edit: to clarify my thinking...
I'm suggesting this might be why users are seeing the error but you can't reproduce the problem. This is one step in troubleshooting I often forget about...
You say that you write to the viewstate when the page is first loaded.
How do you know that it is the first time the page is loaded, is there a navigation route in your app that could by pass the setting.
As a quick fix, you could try checking if the value is null and then returning a default value.
Try to see if there is a connection between the Session_OnError Event in the global.asax and your ViewState problem
See Dynamically adding controls to ASP.NET - viewstate is not retained after 20 minutes
One possible reason for "losing" ViewState content is Output Cache. I'm facing the same problem and the cause is caching (when I disable it, the problem doesn't occur).
We're running a fairly large site, and a lot of our visitors have started using their Android based cellphones to visit the site. However when they try to login, we get an Event Validation error:
Invalid postback or callback argument.
Event validation is enabled using
in configuration or <%# Page
EnableEventValidation="true" %> in a
page. For security purposes, this
feature verifies that arguments to
postback or callback events originate
from the server control that
originally rendered them. If the data
is valid and expected, use the
ClientScriptManager.RegisterForEventValidation
method in order to register the
postback or callback data for
validation.
Does anyone know of a way to fix this, without disabling Event validation entirely ?
It isn't every single time they visit, but it is often enough that it's a problem.
Also we never get these on PC-based browsers (IE, FF, Chrome, Safari, Opera, etc.)
EDIT:
The page this happens on has no updatepanels, no custom __doPostback code, etc. It's pretty much vanilla with a simple LinkButton that causes the postback.
Also this error occurs on a bunch of other pages as well (Just found out about that now), so I doubt it's a lone design fault.
I think it's more likely it's an issue with the Android based browser and ASP.Net in general.
I think I found the answer here:
http://support.microsoft.com/kb/969548
the reason I think this is the case is that I can't duplicate this when I browse normally on my Android simulator, but I CAN if I click on a button before the page ifnishes loading. Also, even the 3G networks are slow enough that this scenario is likely, as impatient users will click as soon as they see the option they want.
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
Ok, so the problem is as follows: I'm using jQuery's AJAX in order to make behind the scene calls within the page (on events such as voting an item) and changing the content in the appropriate element. The problem occurs when I mix AJAX with ASP.net's AJAX, more precisely when I try to do a postback AFTER I've used jQuery on the page to perform an action. The page's viewstate is changed and validation fails (which would seem somewhat normal as a matter of fact).
My question is: can I disable the validation somehow so that I can perform postbacks combined with the chaged page viewstate? So far searching on how to disable it yielded no results.
A more practical example is on a comments page where I allow voting the comments and posting new comments as well. So should a user vote a comment and THEN post his own, the page's contents is changed, and thus validation fails. Also, I've tried placing the comment form within an update panel as to prevent the entire page from posting, but it still fails.
Of course I could use an alternate route and have a different page for handling the event and just call that via jQuery's AJAX, but I was wondering if I could do this by combining ASP.net and jQuery.
Thanks in advance.
If you want to disable viewstate verification, you can set it at the page or config level by using Page.EnableViewStateMac = false.
http://msdn.microsoft.com/en-us/library/system.web.ui.page.enableviewstatemac.aspx
It's not necessarily a good idea though because the validation functionality is there to protect from viewstate tampering, which you'll be turning off...
If you're running into issues with invalid viewstate because of jQuery ajax calls, one option is to consider using the Ajax controls, such as the UpdatePanel. You can wrap certain controls and mark the UpdatePanel as conditional to ensure a small round trip. This will not interfere with viewstate and allow you to continue to use viewstate validation and ajax at the same time.
There may be ways to use jQuery ajax calls and not interfere with viewstate validation. Others may be able to highlight this approach.
We have a web content management system (based on Sharepoint 2007/MOSS, but for the purposes of this problem, that is not relevant, so please stick around even if you haven't worked on MOSS!). On a given page, there are conditions we cannot change:
An editor clicks "Edit" and the page posts back.
When it reloads in edit mode, the control tree is entirely different.
ViewState must be enabled in edit mode, since the edit controls post back frequently
If we disable ViewState in presentation mode, everything works fine. ViewState gets set to "enabled" on the edit postback, the ViewState tree is built up for the first time as the edit controls are generated, and all is well.
If we enable ViewState in presentation mode, when transitioning from presentation to edit, we get a ViewState error because the control tree changes.
We need to enable ViewState in presentation mode, so we need to fix this transition error.
We have tried disabling ViewState during the postback, then programmatically posting back again and re-enabling it, but this causes validation issues with MOSS, so it does not appear to be an option.
Ideas?
Have you tried the clear method on the property bag ;-)
Are you changing the control tree with some advanced information? Typically on the postback you'll rebuild the same control tree before the event handlers for buttons fire (view state should validate at this point) and then handle the event - which may include clearing out previous parts of the control tree.