I think I have found a bug in the LoginView Adapter.  My site uses a LoginView with a LoginButtonType="Link".  When I try to log in the page does not post back.  This is because a false value is being passed to the clientSubmit parameter of the WebForm_PostBackOptions javascript function:

Hi Brendan,

Thanks for finding this problem.  It does, indeed, appear to be a bug.  I'll fix it in the next rev of the kit.

Meanwhile, you (and anyone else using beta 3 of the kit) can fix it locally quite easily.  Look in the adpater code in App_Code\Adapters.  You'll find several adapters that instantiate the PostBackOptions class.

C#
PostBackOptions options = new PostBackOptions(btn, "", "", false, false, false, false, true, changePwd.UniqueID);

VB
Dim options As PostBackOptions = New PostBackOptions(btn, "", "", False, False, False, False, True, changePwd.UniqueID)

Where you find lines like these, you need to change the highlighted parameter from false (False) to true (True).  It is directly responsible for the true/false that you observed in the client-side creation of the WebForm_PostBackOptions object in JavaScript.

I've tested this here but I'd appreciate it if you could reply here to confirm whether or not this fix works for you. Thanks.

Best regards,

You quick fix worked

 Everything looks good but when I hit enter when focus is on one of the text boxes no posback happens this is probably by design but it would be nice if a postback happened.

 Can you magic this for me please? Or give me pointers to magic it for myself?

Thanks

 Brendan

Hmmmmm... talk about pressing your luck... Ha ha.

OK, I'll give it a go.  Try setting the 4th parameter to true when you construct your PostBackOptions object (see code above). I'm not sure that I want to put that change into the kit, though.  It seems like you could end up trying to submit the page before it is filled out because lots of users inadvertantly hit ENTER rather than TAB.  Though, maybe you disagree with that.  Thoughts?

Completely from a usability point of view I think it is a must.  I am developing an application and the two users I tested it on both thought they could not log in as they are that used to being on login forms that when you press enter in the password field you get logged in.  To be honest it even threw me for a few seconds and I must admit I was kinda peaved that I had to click on the login button for it to work. 

That said I do get your point about the tab but if this functionality only lies on the password field they should be ready to login anyway.

What you think?

OK, I can respect that. It's great info, direct from the trenches, so to speak.

Let's turn this around and put you in the hot seat.  I could do the autopostback on just the password field... but then we need to decide how to handle this on the other membership controls.  Do we need to do the autopostback on the last textbox in each of these forms?

Or, do we simply make autopostback true for all textboxes in all forms rendered by the membership control adapters?

Thougts? You're talkin' to the guy who writes the code so you and I can decide right now how to change it for the next rev.  Other readers are, of course, also welcome to chip in on this thread.

Hi Russ,

thanks for getting back to me.  I cannot comment on the other controls as I have not really looked at them much, all I can do is pass on my experience and my clients opinions of the login control.  A lot of sites these days have you logging in when the enter key is pressed in the password field.  Just look at Microsoft and hotmail.

 I think it would be a good feature as to be honest it is confusing if you can autopostback when the button is present but not when the link is there.  It sends out mixed messages.  I know the underlying reasons that it is like it is but it could always be better.

 Any thoughts?

 Brendan

That's fair, Brendan.  Thanks for engaging in this discussion. I'll definitely add the autopostback for at least the password.  I'll look over the other controls on this and other form-producing adapters in the kit... and I'll use my best judgement, for now, to decide which (or if all) should have autopostback.  Look for improvements in the next rev.

Best regards,

Hey Russ thanks for listening I appreciate that my comments have been heard and are actually gonna be used to improve the adapters, it is nice to know you are listening.

 I will be using the adapters a lot more in the future and will leave feedback whenever I can.

Thanks again

Brendan

I'm having problems with this, I'm using buttons and now they submit twice, i've the latest version... All of them are true, and all submit buttons are being submitted twice... I've tested both options on the login button and realized that image and buttons don't need clientSubmit but link does, i've just put a verification on the type of button...

Regards,

Pedro 

Hi,

I downloaded the source this week (5th Feb) and I'm having the double submit problem as well. To try and validate whether it was the adapters causing the problem I built and ran the tutorial and saw the same problem in there.

If you build the tutorial, stick a breakpoint in the Page_Init() method then run the project, when you use the Login example and log in, you will see that Page_Init() is called twice after you click the Login button. The IsPostBack property of the page is true each time.

As a quick fix similar to the one you mentioned in this thread, I changed a line in LoginAdapter.cs (252) from:

PostBackOptions options = new PostBackOptions(btn, "", "", false, false, false, true, true, login.UniqueID);  

to:

PostBackOptions options = new PostBackOptions(btn, "", "", false, false, false, false, true, login.UniqueID);

 (i.e. changed the clientSubmit parameter to false).

This produces an 'onclick' event for the login submit button which matches the one produced by the vanilla Login control (i.e. without the adapters).

This is obviously a different fix to the one you mention for the case when the LoginButtonType is a link - maybe the PostBackOptions specified need to be conditional on the value of LoginButtonType??

Thanks. 

Hi M_Judd, I'm very interested in looking into your issue (noted in this thread on 2-8-2007 at 3:04am). Unfortunately, I can't seem to duplicate the problem. Please help me understand what I've done incorrectly.

As you suggested, I did a fresh installation of the CSS Friendly adapter kit.  Using VWD I created a new C# web site based on the full (tutorial) template from the kit. In the code behind file for the Login example (i.e., in membership\login.aspx.cs) I put a breakpoint in the Page_Init method. I fired up the Login.aspx sample page in the debugger and saw that my breakpoint was hit once. I filled in the username (fred) and password (css!) and pressed the Login button in the form.  That cause my breakpoint in Page_Init to be hit... but just once. I'm not seeing the redundant call to Page_Init that you mentioned.

I'm using Windows Vista (RTM) Business Edition and Visual Web Developer Express SP1. I running using the built-in web server (Cassini).

Any ideas what you and I are doing differently? It looks like you, too, are using the C# version so I don't think the problem is due to differences with C# and VB.  I wonder what else might be going on.

If we can figure out how I can repro the problem I can look at possible fixes. And, even more importantly, I can consider fixing this in a future rev of the kit. However, I can't fix things that I can't verify as being broken... as I'm sure you can appreciate!

Sorry about being dense about this. Please try to be patient and help me figure out what I'm missing. THANKS.

How weird! I just performed the same steps and I still get the Page_Init() called twice on post-back from the login form.

My system details:

OS: Windows XP Tablet PC Edition, with SP 2
Dev Env: Visual Studio 2005 Professional
.Net Framework: version 2.0.50727
Browser: IE 7 (version 7.0.5730.11)

I performed the following steps:

1.) Downloaded the VSI for the CSS Adapters and installed it (choosing to overwrite the existing files downloaded on 5^th Feb 2007).
2.) Opened Visual Studio 2005 and selected File->New->Web Site...
3.) Selected ?Tutorial on ASP.NET CSS Friendly...' and chose C# as the language.
4.) Clicked OK and the webite was created.
5.) Added a breakpoint to ?\Membership\Login.aspx.cs' in the Page_Init() method.
6.) Pressed F5 to run the web site. I was prompted to enable debugging in web.config which I accepted. The web site was running in the ASP.Net Development Server.
7.) The site loaded the Login.aspx page and my breakpoint was hit. I pressed F5 to continue.
8.) I completed the login form using ?fred' and ?css!' then clicked the Login button.
9.) The breakpoint I set in Page_Init() was hit twice. Each time the IsPostBack property was ?true'.
10.) I could log out and log in as many times as I liked and the breakpoint was hit twice each time.

I hope this helps you reproduce this issue. If I can provide any more info, please let me know.

Thanks,

Martin

Hi Martin,

I hate to admit it but... I just tried the recipe and now I see the redundant call to Page_Init, too. I must have been sniffing glue before, or something. Now that I've repro'ed it I can do a better job of figuring out how to fix it. I suspect that we will need to do some sort of "if" check to see what kind of button is being built and set the true/false value (of the parameter we've been discussing) accordingly. I can certainly try to fix this in a future rev of the kit. Thanks for pointing out the problem and being patient with me as I bumble along here.

Russ,

When you check the type of button being created, do you mean the variable btn that is assigned the results of "findcontrol" prior to creating the new postbackoptions? I am testing btn to see if it is a "LinkButton" in which case I create postbackoptions with a client submit of true, otherwise I always give it a client submit of false. Does this sound correct to you?

Thank you,

Erik

Russ,

I wanted to see if any headway has been made on fixing this bug. I have the latest release and it is still present.

The standard login control produces a false as the last param, the adapter control produces a true.

Standard Control = WebForm_DoPostBackWithOptions(new WebForm_PostBackOptions("ctl00$rightcontent$lgnPortal$LoginButton", "", true, "ctl00$rightcontent$lgnPortal", "", false, false))
CSSFriendly control = WebForm_DoPostBackWithOptions(new WebForm_PostBackOptions("ctl00$rightcontent$lgnPortal$LoginButton", "", true, "ctl00$rightcontent$lgnPortal", "", false, true))

This creates double events on all events after submit, not just the Page_Init. In our case, we extend the login to see if it is a users first login and force a password change. In the OnLoggedIn event handler, we check the bit to see if it is a first log in. If it is we redirect to a new page and reset the bit in the DB to false.

When we added the adapter, this functionality stopped working. The redirect is ignored and the bit is set to false, the second even comes in and the bit is now set to false and the user is passed in as authorized without being forced to change their password.

Anyone extending the basic functionality based on events is going to have problems with this bug. It is not the easiest one to track down either, I Googled it before giving up and debugging the issue myself. After that I noticed this entry on the forum, but the time had already been spent.

I know it is easy enough to update this in code ourselves, but if we want to grab the lates versions of controls as they are released it is something that has to be checked each time or a bug will get introduced. In my opinion, this is not a great solution to fixing the problem.

Thanks,

Randy Jones  

Hi Randy, sorry about the long delay in answer your question. Yeah, this bug is a real bummer for folks who happen to run into it. I appreciate that it's hard to track down.

I think the problem you found is the same as what is being discussed in http://forums.asp.net/p/1100637/1676119.aspx#1676119. If so, it has been addressed in the latest version of the adapters being maintained by the community at CodePlex, http://www.codeplex.com/cssfriendly/WorkItem/View.aspx?WorkItemId=234.

Microsoft isn't maintaining or enhancing these adapters now; the community is. This transition was announced in the forum posting that is "pinned" in the box of special forum postings when you visit this forum's landing page, http://forums.asp.net/1018.aspx. The specific posting I'm talking about is http://forums.asp.net/t/1083997.aspx.

Please write back if you want to discuss this more. Again, I wish this bug hadn't made it's way past all of the testing that preceded the release of v1.0 of the adapters. At this point, fixing such problems in CodePlex is the sanctioned way to deal with such issues when they are discovered.