If a user hits backspace in a readonly input field, then we go back in the browser history -- ie, navigate away from the page. Quite bad. Thanks to schnitz for reporting this.

Maybe a readonly input should not be focusable at all? It should at least be removed from the tab order ... or does that contradict the spec.?

Does this happen with HTML forms too and is this trunk only or also branch? I think calling event.preventDefault() and event.stopPropagation() when prosessing keypress (or keyup/keydown) events should fix this.

yep, happens also on branch with HTML controls. using the following in the input (and textarea?) elements seems to fix the problem onkeypress="if (this.readonly) {event.preventDefault(); event.stopPropagation()}"

er, readOnly, not readonly I think.

Well, IE6 is doing the same, pressing backspace on a readonly input goes back in history. What I find strange is that I can see the caret in a readonly field. I can't see it in Mozilla 1.7 (or in IE6). I think that's a regression.

(In reply to comment #6) > Well, IE6 is doing the same, pressing backspace on a readonly input goes back > in history. But do we have to repeat old HTML mistakes in XForms? :)

(In reply to comment #7) > But do we have to repeat old HTML mistakes in XForms? :) Well, I think because you can see the caret, one would think that pressing backspace would delete the characters, but since it is a readonly input, instead you go back in history. The showing of the caret in readonly inut fields changed with bug 193316. So since that is indeed a deliberate move, I think it is indeed a good idea to suppress the default action for backspace in readonly form controls. But I hope it is not only fixed for xforms, but also for html.

(In reply to comment #2) > Maybe a readonly input should not be focusable at all? It should at least be > removed from the tab order ... or does that contradict the spec.? What if a keyboard-only user wants to select some text from the field to copy to the clipboard?

(In reply to comment #9) > (In reply to comment #2) > > Maybe a readonly input should not be focusable at all? It should at least be > > removed from the tab order ... or does that contradict the spec.? > > What if a keyboard-only user wants to select some text from the field to copy > to the clipboard? > Yep, good point. Being able to copy the readonly contents of an input would be nice.

add handler to input (and thus also secret), and textarea

Comment on attachment 217013 [details] [diff] [review] Patch for xforms what about XUL? and don't use tabs ;)

Here's a testcase for XUL too, but I have no idea whether there's a problem there too ... the controls does not seem to be readonly?

Patch without tabs (stoooopid). It also makes the XUL controls readonly, but does not fix the backspace problem. The same handler approach does not work. Follow-up bug?

This fixes it also for html textfields. Not sure whether people will agree with this. But I think it makes sense, especially since you can see the caret appear in readonly textfields now.

(In reply to comment #15) > Created an attachment (id=217027) [edit] > Patch v2 > > Patch without tabs (stoooopid). It also makes the XUL controls readonly, but > does not fix the backspace problem. The same handler approach does not work. > Follow-up bug? > See also Bug 318208.

(In reply to comment #17) > (In reply to comment #15) > > Created an attachment (id=217027) [edit] > > Patch v2 > > > > Patch without tabs (stoooopid). It also makes the XUL controls readonly, but > > does not fix the backspace problem. The same handler approach does not work. > > Follow-up bug? > > > See also Bug 318208. So we should use .readOnly? But it smells like trunk only then?

(In reply to comment #18) > So we should use .readOnly? But it smells like trunk only then? > Could you do something like if ("readOnly" in this.control) { this.control.readOnly = val; } else { this.control.readonly = val; } And add a comment why.

(In reply to comment #19) > (In reply to comment #18) > > So we should use .readOnly? But it smells like trunk only then? > > > > Could you do something like > if ("readOnly" in this.control) { > this.control.readOnly = val; > } else { > this.control.readonly = val; > } > > And add a comment why. Done, but now the event handler for xhtml is not working. This bug is getting more and more fun. I love it. Give me more... :|

(In reply to comment #16) > Created an attachment (id=217169) [edit] > patch for html > > This fixes it also for html textfields. Not sure whether people will agree with > this. > But I think it makes sense, especially since you can see the caret appear in > readonly textfields now. The generic HTML fix should probably be handled in another bug... or this bug should be moved to another component.

(In reply to comment #21) > The generic HTML fix should probably be handled in another bug... or this bug > should be moved to another component. Ok, I filed bug 332811.

Was this checked in? Bug 332811 was fixed, and is likely effecting this bug too (in a sense that the patch might not be necessary anymore).

(In reply to comment #23) > Was this checked in? > Bug 332811 was fixed, and is likely effecting this bug too (in a sense that the > patch might not be necessary anymore). > We would still need to address this on our side of the fence anyhow since bug 332811 wasn't checked into 1.8. Or do you think that we could get 332811 into 1.8?

Ah, ok. No, I don't think you could get the patch in bug 332811 into 1.8, since it's not a critical issue.

RIP xforms