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.
Related
I'm working on tracking down an elusive bug in IE11 and Edge. I've noticed a difference in the network calls between Chrome and Edge, and I'm not sure if that's just a difference between the way the browsers' dev tools display traffic or if it's indicative that something is actually happening in Edge that isn't in Chrome.
The following screenshot is from dev tools in Edge, recorded during page load.
It looks like some request to the server is not considered authenticated, so it's being redirected to the login page. The same page load sequence in Chrome does not show that - it just has the one page request. My first question is - is there a way to track down which thing is making that particular request using the Edge dev tools? Or is this something I need to worry about at all, if it's expected behavior?
Some background on the bug I'm trying to resolve
The page uses UpdatePanels and jQuery ajax both to make requests to the server. The relevant jQuery ajax calls are made in click events triggered on objects inside the update panels. I've verified that those click events aren't triggering a postback. The click handlers seem to be executing just fine (most of the time), but the bug is that sometimes they don't seem to be executed at all - none of my console.log statements appear in the console, and nothing happens (except the page jumps a little) until you click again. Every other click seems to work. It seems to happen when there is a lot of data loaded on the page (note the load time for the first request in dev tools).
I've made sure to rebind the click events that are on the objects inside the update panels after each update panel postback using
Sys.WebForms.PageRequestManager.getInstance().add_endRequest
The site uses forms authentication. There is just one server on the site I'm testing on - no load balancer involved.
Also - before anyone suggests it - we are trying to move away from the update panels, but we're not quite ready to retire this page which relies heavily on them. That would be my preferred solution, too :)
You mention that the webpage concerned is large.
Because of this, the JavaScript onload will not always have been completed yet when you do a quick first click on such a clientside hyperlink/button, which means that a regular http GET request gets triggered, which you see in the developer tools.
You will also see this in other browsers.
Try to find a way to disable these clientside hyperlinks/buttons before the onload has finished.
You could disable them initially via:
<a class="clientsideButton" href="#" onclick="javascript:return false">click here</a>
And enable them afterwards.
Don't forget to also re-bind them again after a partial postback!
<script>
$(function() {
$(".clientsideButton").on("click",
function() {
// Make AJAX request.
});
});
</script>
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.
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.
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?
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