The default bug view has changed. See this FAQ.

backspace in readonly input triggers history.back()

RESOLVED WONTFIX

Status

Core Graveyard
XForms
--
enhancement
RESOLVED WONTFIX
11 years ago
9 months ago

People

(Reporter: Allan Beaufour, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments, 3 obsolete attachments)

(Reporter)

Description

11 years ago
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.
(Reporter)

Comment 1

11 years ago
Created attachment 216826 [details]
Testcase
(Reporter)

Comment 2

11 years ago
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.
(Reporter)

Comment 7

11 years ago
(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.

Comment 9

11 years ago
(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?

Comment 10

11 years ago
(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.
(Reporter)

Comment 11

11 years ago
Created attachment 217013 [details] [diff] [review]
Patch for xforms

add handler to input (and thus also secret), and textarea
Assignee: aaronr → allan
Status: NEW → ASSIGNED
Attachment #217013 - Flags: review?(smaug)
Comment on attachment 217013 [details] [diff] [review]
Patch for xforms

what about XUL? and don't use tabs ;)
Attachment #217013 - Flags: review?(smaug) → review-
(Reporter)

Comment 13

11 years ago
Created attachment 217025 [details]
Testcase - xhtml
Attachment #216826 - Attachment is obsolete: true
(Reporter)

Comment 14

11 years ago
Created attachment 217026 [details]
Testcase - xul

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?
(Reporter)

Comment 15

11 years ago
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?
Attachment #217013 - Attachment is obsolete: true
Attachment #217027 - Flags: review?
(Reporter)

Updated

11 years ago
Attachment #217027 - Flags: review? → review?(Olli.Pettay)
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.
Attachment #217027 - Flags: review?(Olli.Pettay) → review-
(Reporter)

Comment 18

11 years ago
(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.
(Reporter)

Comment 20

11 years ago
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... :|
Attachment #217027 - Attachment is obsolete: true
(Reporter)

Comment 21

11 years ago
(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.

Updated

11 years ago
Depends on: 332811
(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.

No longer depends on: 332811
(Reporter)

Updated

11 years ago
Severity: normal → enhancement
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).

Comment 24

10 years ago
(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.
(Reporter)

Updated

10 years ago
Assignee: allan → xforms
Status: ASSIGNED → NEW
RIP xforms
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.