Last Comment Bug 332345 - backspace in readonly input triggers history.back()
: backspace in readonly input triggers history.back()
Status: RESOLVED WONTFIX
:
Product: Core
Classification: Components
Component: XForms (show other bugs)
: Trunk
: All All
: -- enhancement (vote)
: ---
Assigned To: xforms
: Stephen Pride
Mentors:
http://www.w3.org/TR/xforms/
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-31 02:28 PST by Allan Beaufour
Modified: 2016-02-04 12:20 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase (1.32 KB, application/xhtml+xml)
2006-03-31 02:28 PST, Allan Beaufour
no flags Details
Patch for xforms (1.66 KB, patch)
2006-04-03 04:11 PDT, Allan Beaufour
bugs: review-
Details | Diff | Review
Testcase - xhtml (1.56 KB, application/xhtml+xml)
2006-04-03 07:33 PDT, Allan Beaufour
no flags Details
Testcase - xul (1.21 KB, application/vnd.mozilla.xul+xml)
2006-04-03 07:34 PDT, Allan Beaufour
no flags Details
Patch v2 (2.66 KB, patch)
2006-04-03 07:59 PDT, Allan Beaufour
bugs: review-
Details | Diff | Review
patch for html (1.38 KB, patch)
2006-04-04 09:57 PDT, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
no flags Details | Diff | Review
Patch w/ readonly/readOnly (2.67 KB, patch)
2006-04-05 01:25 PDT, Allan Beaufour
no flags Details | Diff | Review

Description Allan Beaufour 2006-03-31 02:28:10 PST
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.
Comment 1 Allan Beaufour 2006-03-31 02:28:53 PST
Created attachment 216826 [details]
Testcase
Comment 2 Allan Beaufour 2006-03-31 02:32:20 PST
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.?
Comment 3 Olli Pettay [:smaug] 2006-03-31 03:16:11 PST
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.
Comment 4 Olli Pettay [:smaug] 2006-03-31 03:22:23 PST
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()}"
Comment 5 Olli Pettay [:smaug] 2006-03-31 03:24:21 PST
er, readOnly, not readonly I think.
Comment 6 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2006-03-31 04:17:02 PST
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.
Comment 7 Allan Beaufour 2006-03-31 04:21:24 PST
(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? :)
Comment 8 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2006-03-31 04:41:47 PST
(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 Justin Kerk 2006-03-31 07:50:00 PST
(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 aaronr 2006-03-31 11:50:06 PST
(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.
Comment 11 Allan Beaufour 2006-04-03 04:11:45 PDT
Created attachment 217013 [details] [diff] [review]
Patch for xforms

add handler to input (and thus also secret), and textarea
Comment 12 Olli Pettay [:smaug] 2006-04-03 06:48:51 PDT
Comment on attachment 217013 [details] [diff] [review]
Patch for xforms

what about XUL? and don't use tabs ;)
Comment 13 Allan Beaufour 2006-04-03 07:33:44 PDT
Created attachment 217025 [details]
Testcase - xhtml
Comment 14 Allan Beaufour 2006-04-03 07:34:37 PDT
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?
Comment 15 Allan Beaufour 2006-04-03 07:59:47 PDT
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?
Comment 16 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2006-04-04 09:57:02 PDT
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.
Comment 17 Olli Pettay [:smaug] 2006-04-04 11:41:07 PDT
(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.
Comment 18 Allan Beaufour 2006-04-04 12:01:53 PDT
(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?
Comment 19 Olli Pettay [:smaug] 2006-04-04 12:06:11 PDT
(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.
Comment 20 Allan Beaufour 2006-04-05 01:25:24 PDT
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... :|
Comment 21 Allan Beaufour 2006-04-05 01:27:15 PDT
(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.

Comment 22 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2006-04-05 04:51:13 PDT
(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.

Comment 23 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2007-02-19 09:28:43 PST
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 aaronr 2007-02-19 11:42:41 PST
(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?
Comment 25 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2007-02-19 11:46:51 PST
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.
Comment 26 David Bolter [:davidb] 2016-02-04 12:20:54 PST
RIP xforms

Note You need to log in before you can comment on or make changes to this bug.