CodePlex Home
Register | Sign In | CodePlex Home
9 votes
closed
Adapters Cause Double PostBack in IE

Description

 
I mentioned this on my blog before I realized that the Adapters had been moved over to CodePlex - so I'm reposting the issue here. :)

============

I've been using the CSS Adapters along with the Membership/Roles/Provider controls and I've come across an issue where the Adapters cause the page to PostBack twice when using IE. (I tested using IE7 and FF 2.0... but others have confirmed the issue exists in IE6 as well).

For example, when using the CreateUserWizard and it's Adapter, clicking the submit button (which kicks off the CreateUserWizardStep) causes the page to PostBack twice in a row.

From an end-user point of view an error message is displayed on the screen, and rightly so. By stepping through the code in debug mode, I was able to verify that the first PostBack successfully created a user (and the user shows up in the aspnet_Membership table). However when they wizard tries to create the user for the 2nd PostBack it fails because the user already exists. Hence, an error is thrown and shown to the user.

A similar situation occurs with the PasswordRecovery control - the password is actually reset twice, and two emails are sent to the user.

I've also confirmed this to be an issue with the ChangePassword control - the password is successfully reset on the first request, but the second request fails because the "old password" value passed in the request is no longer valid.

You can confirm the double PostBack using Fiddler.
1. fire up Fiddler and go to a page using one of the above controls (and their respective Adapter of course).
2. Use the control.
3. Look in the Fiddler HTTP Sessions window and you'll see duplicate POST requests for the same page.

The only work-around I've found so far is to disable the Control Adapter for the CreateUserWizard and PasswordRecovery controls.

So, to recap:
* using RTM version of CSS Adapters
* using asp.net 2.0 Membership/Profile/Roles controls with CSS Adapters
* using WebApplicationProject (WAP) model
* Membership controls + CSS Adapters work fine with FF 2.0
* some (possibly all?) Membership controls + CSS Adapters cause double PostBack with IE7 (and others have confirmed same issue with IE6).

====================

Please let me know if there is anything further I can do to help...

You can see my original post about the issue here: http://stevenharman.net/blog/archive/2007/04/18/css-control-adapters-cause-double-postback-in-ie.aspx

File Attachments


Closed Jul 20 2007 at 9:39 PM  by bdemarzo

Comments

most recent at top (show oldest at top)
bdemarzo wrote Jul 22 2007 at 2:31 AM
Yes -- see my comment just below yours. The patch is already applied.

DerekS wrote Jul 21 2007 at 2:30 PM
Does the change of this issue's status to "closed" mean we will see a new version shortly with the fix in?

wrote Jul 20 2007 at 9:39 PM
Resolved with changeset 3704.

Azavia wrote Jun 4 2007 at 5:30 AM
Hello,

Is there any further work on this issue? I'm having the same problem.

I solved the above-mentioned problem for now by removing lines 486-488 in WebControlAdapterExtender.cs, where it has:

case ButtonType.Button:
etc...

I also made some other fixes, like checking if AutoGeneratePassword is set to true so the password fields aren't displayed if so, and refilling the fields with the previous text, since it was only doing that for the username.

Now I'm having the problem that the page after the initial registration page has a continue button, but keeps going back to the same step. it seems unfortunately this adapter is still quite buggy. :(

In case it helps, attached is my modified version.

cinnio wrote May 23 2007 at 6:26 PM
Hi everybody.
I've applyed Tana changes, and now actually tha page is posted back just once
BUT
I can't handle any event from the control no more (eg: OnSendingMail, OnCreatedUser,...) and also users are not created at all.
Am i missing something?

thanks

bdemarzo wrote Apr 22 2007 at 3:04 AM
More fix info here: http://forums.asp.net/1676119/ShowThread.aspx#1676119

Any feedback on these proposed solutions is appreciated.

ussherm wrote Apr 22 2007 at 2:15 AM
Brian,
I can confirm that the proposed work around does work, but it is not the correct fix. As I mentioned to my email (and blog comment) to you, I looked into why this workaround... um... works - and I actually came to the same conclusion that Tanna proposed at the CSS Adapters forums (http://forums.asp.net/1676119/ShowThread.aspx#1676119).

The gist is, each of the offending adapters (ChangePasswordAdapter, CreateUserWizardAdapter, LoginAdapter, PasswordRecoveryAdapter) uses the PostBackOptions class to generate the Javascript that is attached to the controls' submit button/link. One parameter for the PostBackOptions constructor is a bool value, isClientSubmit.

isClientSubmit == true -> clicking the button/link will submit the form via Javascript.
isClientSubmit == false -> clicking the button/link will not submit the form via Javascript.

If the button type used for the adapters is button or image, then the form will automatically be submitted by the browser b/c the DOM element is already an input element, so it does not need to be submitted by via Javascript. However, a link will not cause a POST by the browser, so it needs to be fired via Javascript.

Right now each of the offending controls are sending true for the isClientSubmit param, but they should only be sending true if the control is using a Link for the ButtonType.

Tanna does a great job of explaining the issue (and some other side-issues) in full detail at the above mentioned forum post.

I've pulled down the latest change set and I'll apply the necessary changes and generate a patch file to submit. However, I'm not very familiar with TFS (I've only ever used it for one project, BlogML), so is there a standard patch-generation tool? We use Subversion for Subtext and it has built-in patch generation and application... but that won't help much here :). I could generate a patch file using WinMerge if that helps?

-Steve

bdemarzo wrote Apr 21 2007 at 4:04 AM
A comment on your blog proposed this as a fix:

Change: PostBackOptions options = new PostBackOptions(btn, "", "", false, false, false, true, true, changePwd.UniqueID);

to: PostBackOptions options = new PostBackOptions(btn, "", "", false, false, false, false, true, changePwd.UniqueID);

I don't have a convenient test environment available, but if someone does and wants to test this, please let us know the results.

Updating...
© 2006-2009 Microsoft | About CodePlex | Privacy Statement | Terms of Use | Code of Conduct | Advertise With Us | Version 2009.10.27.15987