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.
Related
I have an ASP.Net web app which has a page with various GridViews shown in Jquery tabs. This works fine in Firefox and Chrome but the page is slow to render in IE. So I thought instead of loading all the gridviews at once, i'll just load them as and when the user clicks on a tab.
So I have set up a new aspx page which accepts parameters of what to show. This all works fine in all browsers and the page is now nice and fast in IE.
However, IE has come to bite me again, because as soon as the page hits a postback it generates this exception:
The state information is invalid for this page and might be corrupted.
From what I can understand this is because the GridView control that is loaded via AJAX has to be inside a <form> tag with runat="server" and this is changing the viewstate of the overall page. So when it postbacks the original page it seems to have lost its viewstate.
I then tried to turn off the viewstate in the aspx being included. Via EnableViewState="false" but this still doesnt work.
I'm confused how Chrome and Firefox are ok, but only IE is getting the ViewState error. Is there anything else I can do to ensure the sub-page does not alter the ViewState in IE?
Perhaps if ASP.Net didnt detect the browser as being IE, it wouldnt do whatever it is doing to break the page?
Set the enableEventValidation attribute in the web.config file for the asp.net application to false.
If using IIS6, make sure IIS compression is turned off.
If is possible, add OnClientClick event to button, that cause the postback, and call a function that removing added controls via ajax.
In the end, after lots of research I don't think what I was trying to do is possible.
As a work around I opted to insert an iFrame within the jQuery tabs, and then load the gridview in that. This then doesnt upset the viewstate of the parent page.
I having an issue with the ASP.NET Treeview control. I create the treeview just fine but the nodes will not expand or collapse. I see there is a javascript error but it is for line 1 character 0 of the webpage, there is nothing at line 1 character 0.
I am using the ASP:Treeview control in conjunction with the Telerik controls, but I'm not sure if that is an issue.
I saw there was a similar question here but the answer is not pertinent to my site. Has anyone run into this issue before? I've tried searching Google and tried a number of proposed solutions but so far none have worked.
Thank you,
Normally with problems like this it is best to isolate the code which is causing the problem. For example, create a minimal page with no other controls or external JavaScript and see if the problem persists.
It's also useful to use a decent debugger. The latest IE8 actually has a very good Visual Studio-style JavaScript debugger built in - go to your page, hit F12 and the go to the Script tab and click 'Start Debugging' and see where that leads you.
I've seen unhelpful javascript errors when a page does an AJAX postback, an exception occurs on the server, and the client javascript is unable to handle what the server returns. You could ascertain if this is happening by debugging the site, putting a breakpoint on the Page_Load method (or something similar), and see if it gets hit when trying to collapse or expand the TreeView.
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.
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