At work, we are developing a complex webForms app. We are using Visual Studio 2010 to develop a framework 4.0 site in C# 4.0.
We have been experiencing random behavior on post. Here is what we have seen:
<Button> tag with a runat server and a ServerClick event will SOMETIMES run the Click event twice (Average 80% twice) - Converted to asp:Button control and it always fired its click event once. So, we called that 'fixed'.
<asp:DropdownList> control with autopostback=true. We are seeing similar behavior. We have two UserControls that have an <asp:DropdownList> with autopostback=true inside. When two of these UserControls are displayed at the same time, If you click one of them, it calls the OnChange event for both DropdownLists. (Average 40% both called)
We have determined that this is not a client side issue. Fiddler 2 shows that we are filling the EventTarget correctly and that both of the DropdownLists' values are correct on post.
At a guess, it seems that the __DoPostBack "part" of asp.net 4.0 has an issue since that is the only thing that these two similar issues shared. Has anyone else seen issues like these and are their any tips/tricks to solve this?
(BTW, converting to a older version is not an option. We are heavily using some of the new features in 4.0)
Related
I thought including ajax control toolkit is a simple thing, but for some odd reason it's not working. It always triggers a full postback from a button inside UpdatePanel.
I am using VS 2015 / asp.net 4.6.1 / Class Library output type. ajaxcontroltoolkit.dll v18.1.1 is added via Nuget. I created a very basic web form page with only an update panel and a label outside of it. Clicking on a button inside update panel always causes a full post, updating the label outside along with it.
Oddly enough, I created a blank Web Site project with the same page and code behind, and it works fine as expected there.
I use browser debugging tool to observe the network output. The site that works appears to have 1 reference to WebResource.axd and 2 references to ScriptResource.axd. Versus the site that doesn't work having only 1 reference to Scriptresource.axd and none to WebResource.axd.
Is there something I missed? Any further techniques I can use to troubleshoot the problem?
One full day of trouble shooting. This setting in web.config prevents ajax control toolkit from performing partial page load.
https://weblogs.asp.net/scottgu/gotcha-don-t-use-xhtmlconformance-mode-legacy-with-asp-net-ajax
We are in the final stages of moving an older web application from the asp.net 2.0 environment to asp.net 4.0. We've got everything ironed out but a file upload implementation.
We use an asyncfileupload control within a JQueryUI modal dialog...which runs well under 2.0 but not under 4.0, the control simply does not fire the UploadedComplete server-side event.
Our testing indicates the same code will run outside of the JQueryUI dialog, but not when in the dialog...so we assume the issue relates to JQueryUI under 4.0.
Seen one or two very old posts suggesting JQuery moves the upload control outside the form element, and thus the control doesn't fire, but that doesn't answer the question as to why our original implementation runs under 2.0 but not 4.0.
Any guidance would be appreciated.
Have you tried setting the right enctype="multipart/form-data" .
Hope these links already answered ,gives you some help
StackOverFlow,
ASPNet-Button-do-PostBack-in-jQuery-Modal-Dialog-Popup
We have a .NET 4.0 WebForms app. One page has an UpdatePanel containing some HtmlButton controls. This was working correctly when the server was running on .NET 4.0.
When the server was upgraded to 4.5 we noticed that clicking the buttons would hang the browser. The spinner would show, and the user's session was essentially locked until the call timed out.
In the Network tab of the browser dev tools (F12) we observed:
IE10 using Standards Doc Mode: Two calls are made to the server. The first one has no content and the Result is "(Aborted)". Fiddler reports a content-length mismatch. The 2nd call doesn't return until it times out.
IE10 Compat View, Doc Mode IE7 standards: Only a single call is made to the server. All is fine.
IE10 in any other mode (and also IE9) makes the 2 calls to the server with the first aborted and the 2nd hung/pending.
Chrome: Two calls are made to the server, but the 2nd one succeeds.
Carrying out the same observations against a server running .Net 4.0 showed similar double-calls, but in no instance did the 2nd call hang.
I recreated this double-call behavior (apart from the hung 2nd call) by creating a new default .Net 4.5 WebForms app with an UpdatePanel, a Literal and a HtmlButton like this:
<asp:UpdatePanel ID="UpdatePanel1" runat="server">
<ContentTemplate>
<asp:Literal ID="myliteral" runat="server"></asp:Literal>
<button id="htmlbtn" runat="server" OnServerClick="htmlbtn_Click"></button>
</ContentTemplate>
</asp:UpdatePanel>
The ServerClick event just puts the current time in the Literal.
This recreated the double-post behavior. I also tried using other types of button such as an ImageButton and they worked correctly only issuing a single call.
Does anyone know what is going on here? Is there any way to avoid the double-post using the HtmlButton? I am assuming that the 2 calls are related to the the hanging 2nd call, but that could be a bad assumption.
It turns out that their was some jQuery binding going on for each partial page request that wasn't being unbound before being bound again.
During jQuery's $(document).ready() I was setting up bindings to various elements. This function was being called during partial post backs caused by UpdatePanels. So in some cases what I needed to do was something like the following before setting up the binding again: $('#ctrl').unbind(); (There is probably a way to check if a binding exists and only add it if necessary.)
Also there is an textarea using a jQuery autoresize plugin on the page. When initialized the plugin adds a clone textarea off the page which is used to calculate the text height. On each partial page update a new one of these text areas was being created. Using Chrome's dev tools was useful to find this issue as I could see the DOM being changed in real time. I added some script to check for these existing text areas and clean them up.
I am currently working with ASP.NET and the person who designed the form has used all Server Controls for things like TextBoxes and Dropdowns etc when really they are not providing postbacks.. Some of the dropdowns and textboxes are values that I need only in jQuery so as far as I can see there are no drawbacks to coverting these controls to standard html controls rather than ASP.NET server controls?
I suppose I will need to continue to have my GetDataGrid button as a server control because I will need it to postback (and receive PageLoad events etc - all asp.net events) to update the GridView? Or would it be possible to use the GridView (ASP.NET server control) from a Webmethod and call it via Jquery?
Of course in my webmethod I would need to the instance of the gridview to add the datasource - but I don't see how this would be possible without being in the ASP.NET events - or maybe I wrong?
The other thing I thought of was changing the GetGridView button to a standard HTML and calling the javascript postback from the client click event?? This way it would do a real postback and I would end up in Page_load.
Taking everything into effect i don't want to the change the GridView asp.net control as it funcions well as an asp.net server control but i am unsure how i would do this.
I remember a document being available that said "how to use asp.net webforms without server controls" but i can't seem to find it. I suppose using webforms like asp.net MVC - but i can't change the project to MVC - its out of my control.
I would love to hear some feedback with regards to how to do this or comments etc.
I find ASP.NET webforms to inject a lot of code smell into pages - I am using .NET 3.5 so a lot of the output is with tables etc...
If you use Request.Form["..."] then you can get the information which was filled in in standard html input fields.
Instead of keep on using the GridView control I suggest you take a look at either jqGrid or the new templating system that Microsoft put into place for jQuery (currently a plugin but expected to be part of core jQuery from version 1.5 on). These can bound to json which can be retrieved from a webmethod or pagemethod call to fill up the template with data.
Also i don't think its possible from asp.net (code behind) to receive values of an html >control without it having runat=server.
Use webmethods.
Set a client event (like 'onchange') on the html control and then in javascript function called when the event is fired you can use PageMethods to send your data to the code behind.
Some thoughts...
The GridView can't be created in a WebMethod and even if there was a way to get that to work, you'd be better off going with a genuine client side grid. As that's not an option, I don't think there is too much point in trying to make any major changes to your existing pages.
ViewState
Changing the textboxes, buttons etc to HTML versions, would gain you a little bit in reduced Viewstate size but add a bit of complexity in how you handle interactions with the page. You can add runat="server" to HTML controls which will give you control over what is rendered and still have access to the control on the server side.
.Net 4 gives you far more control over viewstate but unfortunately in 3.5 its not as easy.
The GridViews
You could wrap the GridViews in UpdatePanels. That's a 'cheap' way to add some interactivity to your pages although you won't be gaining anything in terms of performance.
It's also still possible to manipulate the Gridview using jQuery on the client-side. There a lots of tutorials, blog posts etc explaining how to do this on the Internet.
MVC with Webforms
Its also possible to mix ASP.Net MVC with Webforms in the same website. As it sounds like you are familiar weith MVC, you might want to consider this approach for any new pages. Here's a blog post explaining how to do this.
Update:
Here's a more recent article by Scott Hanselman on how to use MVC with an existing Webforms application.
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.