4

I have a disabled TextBox that I am editing the value of on the client side with JavaScript. When I try to retrieve the value on the server side it does not reflect the change made on the client side. If I set the TextBox's enabled attribute to true I can retrieve the value, but the user is able to put focus and edit the TextBox.

Is there a sane way to keep the user from giving focus and editing to the TextBox?

Slim
  • 5,635
  • 7
  • 31
  • 30

2 Answers2

6

Use the textbox's ReadOnly property.

Edit: Based on OP's comment, this will probably not do the trick then.

Edit 2: From DotNetSlackers:

So what's the difference between these two properties and why do both exist? There are two differences between these two properties, a trivial difference and a subtle, profound one:

  1. The two properties emit different markup. When you set Enabled to False, the TextBox injects the attribute disabled="disabled" intoits rendered HTML. When you set the ReadOnly property to True, the attribute readonly="readonly" is injected.
  2. According to the W3C spec on HTML forms, disabled controls areNOT "successful," while read-only controls MAY BE "successful." A "successful" control is one whose name/value pair is sent back to the browser through the POST headers or querystring. Therefore, disabled controls are NOT sent back to the ASP.NET page, while read-only controls may be, depending on the User Agent. (In my tests,both IE 6and FireFox 1.5 send along the read-only TextBox input.)

......

If you encountered this problem in ASP.NET version 1.x you might have found the TextBox's ReadOnly property and used that instead of setting Enabled to False. You could still have a page's ViewState disabled and set a read-only TextBox Web control's Text property programmatically because the TextBox value is sent back through the form submission for read-only controls. However, in ASP.NET version 2.0, things change just a bit, as noted by Rick Strahlin his blog entry ASP.NET 2.0 ReadOnly behavior change when EnableViewState is false. With 2.0, the TextBox control'sReadOnly property's behavior has changed slightly. From the technical docs:

The Text value of a TextBox control with the ReadOnly property set to true is sent to the server when a postback occurs, but the server does no processing for a read-only text box. This prevents a malicious user from changing a Text value that is read-only. The value of the Text property is preserved in the view state between postbacks unless modified by server-side code.

What happens is that the client sends along the value of the read-only TextBox through the form values, but the ASP.NET 2.0 engine does not take that value and assign it to the Text property of the TextBox on postback to help protect against a malicious user changing the read-only TextBox value themselves. But this brings us back to our earlier problem - if the value isn't specified in the postback (or is ignored, in this case) and ViewState is disabled, the value will be lost. Eep.

Rick'sworkaround was to just manually read the value from the request headers (this .TextBox1.Text = Request[this.TextBox1.UniqueID];), which poses a security risk and introduces the problem that 2.0 addresses. The optimal approach is to requery the value from the database (or wherever you initially got the programmatically-set value for the read-only TextBox).

The moral of this blog post is that if you have read-only data you can use either disabled or read-only form fields, it really doesn't matter whether or not you receive back the value of the form field in the form's submissions. It shouldn't matter because you shouldn't be trusting/using that data to begin with! If you have read-only data, don't re-read it from a data stream that the end user can tinker with!

Source

TheTXI
  • 37,429
  • 10
  • 86
  • 110
  • If you set the textbox's readonly property to True, it will remain enabled but blocked from user-input. – TheTXI Apr 29 '09 at 15:53
  • Setting ReadOnly to false does the same as setting enabled to false. – Slim Apr 29 '09 at 15:54
  • Well if that's the case, then I have lost a heck of a lot of respect for the ReadOnly property. – TheTXI Apr 29 '09 at 15:55
  • I intended to say setting ReadOnly to true does the same as setting enabled to false. – Slim Apr 29 '09 at 16:01
5

Browsers don't post values back in disabled input controls, as you've discovered. Probably the easiest way to work around this is to hook onto form submission, and re-enable the input as the form is being submitted; the user won't have a chance to edit the value, and it should get posted with the rest of the request.

An alternative might be to inject a hidden element into the form; this could either be maintained by your script, mirroring the displayed value, or added at the end, in a similar fashion to the above.

Rob
  • 47,999
  • 5
  • 74
  • 91
  • What I ended up doing was what Rob suggested. I added a asp:HiddenField to the page. When the JavaScript changed the value of the TextBox on the client side it also changed the value of the HiddenField. Then the new value was accessible on the server side through the HiddenField. It's a bunch of convoluted crap, but thats why they call it brown-field. – Slim Apr 29 '09 at 21:39