I'm using the ASP.NET Membership provider and using the Password Recovery control to reset the user password if they forget it. On the whole it all works fine, but with one catch when it comes to validation.
I have expanded the PasswordRecovery control out to use the template feature to customise the appearance, which is all fine. I have set the user lookup error handler using:
OnUserLookupError="PasswordRecovery1_UserLookupError"
in the opening tag and if I load up the page, type in some junk name and click submit this fires as expected, in all browsers. The snippet of VB code makes an error div visible and sets some text.
However, if upon loading the page for the first time I type a duff name into the username box and hit the enter key to submit the form, in Internet Explorer (version 8), the UserLookupError event fails to trigger. It triggers just fine in Chrome or Firefox, just not in IE. I know it's not a focus issue on the form, as I can see the form is being submitted.
If I click the submit button first, then following that hit the enter key it does fire, it's just that first time it doesn't, and only in IE.
Also to add that if I set breakpoints in the VB code to check to see if the page is being submitted, I can see the Page_Load event fire when I hit the enter key, but not the sub PasswordRecovery1_UserLookupError.
Has anyone else seen this? It looks like a bug in IE (no really???), but I need to nail it down.
Any help would be welcome.
OK, after some more digging and testing this is actually only a default button issue. I'm not sure what's happening when the enter key is being pressed (only in IE) after text has been entered in the box, as it is reloading the page but not submitting it. There is no other control or function on the page which would navigate back to or refresh this page.
Despite the submit button appearing to be the default button it actually isn't. The key here therefore is setting the defaultbutton property of the webform. That however, when the button is inside a PasswordRecovery control is another issue.
EDIT:
Here's the fix. Set the default button at the page load stage.
Me.Form.DefaultButton = PasswordRecovery1.UserNameTemplateContainer.FindControl("SubmitButton").UniqueID
Related
I have 2 pages.
Login page
Search page (after login)
On my search page, I have several input box (text, radio, checkbox ...) .
The problem is, when the cursor is at one of the input fields, and the user presses Enter, the browser send the user back to the login page.
I fixed this issue using JQuery to capture keypress event on input items. However I still don't understand why is this happening?
P/s : if you need to see my HTML code please comment. The code stays on my work computer with restricted access so I can't post it here, but I will type it here if necessary.
Place your input inside a panel and set the default button to your default control.
<asp:Panel runat="server" ID="pnlForDefault" DefaultButton="btnSearch">
<!-- your input -->
</asp:Panel>
Now why is going back - and why I show you this panel method.
1. Maybe because you all ready have this panel on your page with wrong default button.
2. The user can press enter either when its on a text box, but also at any time, but only when the focus is inside a text box can be actually redirect that enter to some control. So either you may have some other library that take action on enter, either you press enter when you are focus on go back button....
You can also read
Default button not working in asp.net panel
I have some input fields, regular expression validators, and custom validators inside an ASP.NET ASCX control. The behavior is a bit odd in that it works the following way:
If a client side validator flags an error message and I tab away from the input field and click submit then the page posts as it should. However, if a client side validator has flagged an error and instead I correct the error and click submit button then the error is cleared but the page is not submitted until I click the submit button a second time.
My question is how do I change this behavior such that I only need to click the submit button once to both clear the error and postback the page? Also, is this "behavior" standard?
Update: This behavior occurs without using the user control. I believe it is specific behavior to the CompareValidator. Nope, same behavior occurs with custom validator. If I don't "tab away" and click the button then I must click it twice to get the postback to occur. The first click just clears the validators.
The issue is that the CustomValidator has display type as Dynamic and not Static. This post helped me to discover the answer
RequiredFieldValidator have to click twice
I will give credit for anyone who explains why it causes this behavior.
I have a couple of pages with standard asp.net validation controls such as RequiredFieldValidator etc inside my RadAjaxPanel.
As soon as I navigate to another tab in my RadTabStrip the page seems to force validation errors and pretty much "locks" the page even though non of the fields was selected to enter data.
Only once all the required fields was entered the page seems to release the "lock" and only then am I able to navigate to another tab / page without even submitting the page.
Any idea what might be causing the "lock" and forced validation errors on the page?
Thanks
The RequiredFieldValidators are failing as the fields are empty. These validators are fired client side and so they're stopping the postback (which will change your tab) from occurring.
I'm not sure how the tabbing works on a RadTabStrip, but for normal ASP Buttons there's a "CausesValidation" property on the button. If you set it to false, it'll stop any validators from being fired when pressed.
I have a web page that has a button that when clicked will download a file for the user. However after the download if the user clicks on the back button the previous form is displayed but the form fields are all blank.
If the user clicks back without performing the download then the form fields are automatically repopulated by the browser as expected.
This bug happens in IE6 and 7 but seems to be OK in 8 which suggests it was a bug that has been fixed in IE8.
Anyone have any idea how I might work around this in IE6 and 7?
There is definitely nothing you can do on the server side, as the browser does not inform the server when the user presses the back button. I'm not even certain if the browser has an event that you can use JavaScript to capture, but if there is a solution, it would have to occur on the client side.
I think we are going to rewrite the page to replace the use of the browser back button with a postback to return the user to the original page. Then we can pass the original form data back and repopulate the form programatically.
I have a page where I submit some data, and return to the original form with a "Save Successful" message. However, the user would like the ability to return to the previous page they were at (which contains search results) by clicking the browser's "Back" button. However, due to the postback, when they click the "Back" button they do not go to the previous page ,they simply go to the same page (but at its previous state). I read that enabling SmartNavigation will take care of this issue (postbacks appearing in the history) however, it has been deprecated. What's the "new" best practice?
*Edit - I added a ScriptManager control, and wrapped the buttons in an UpdatePanel, however now I'm receiving the following error:
Type 'System.Web.UI.UpdatePanel' does not have a public property named 'Button'
Am I missing a reference?
*Disregard the above edit, I simply forgot to add the < ContentTemplate > section to the UpdatePanel :P
If you put your "Save" button in an UpdatePanel, the postback will not show in the users history.
I would avoid if possible. A better solution would be to have a button that just returns them to their search results on the "Save Successful" screen.
The problem with the ajaxy saving and such is that you violate the "Back" rules that users expect. This user might want the Back button to go back to the Search page, but other users might expect that clicking Back would return them to the Add/Update page. So if another user tries to update something, clicks save, and then "woops, i forgot something on the update", they'll click back, and now they're at search results, instead of the expected Update page.