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()}"

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 #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.

Created attachment 217027[details][diff][review]
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?

Created attachment 217169[details][diff][review]
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.

(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.

Created attachment 217269[details][diff][review]
Patch w/ readonly/readOnly
(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 #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?