a XUL textbox should have a 'filter' property whose value is a regexp; the user will only be able to enter characters as long as the contents of the textbox match the regexp. If the property is null or zero length than no filtering is done (the default). And don't tell me I should wait for XForms or something...

I can't see this happening without help from Editor - specifically, some way of telling editor to abort the edit that just occurred. Otherwise every time you need to "correct" the input you lose the regular undo, which is unreasonable. An onchange filter would be much less hassle as when it fires the user is unlikely to need to undo. Futhermore if only input events that matched the filter were allowed to propagate this would simplify user event handlers.

When I try to insert or delete text then I match possible text changes by the regexpr. If possible text changes is matched then I replace old text with possible text changes. There is no one simplification of user events. All keyboard events will be fired. But if possible text changes don't match with regexpr then changes aren't applied and input event is not fired. If nothing was changed then nothing cannot be undo. Such widget can be build on textbox widget. It's needed to handle all keyboard events and prevent them if they are unsuitabled. Such widget has good advantages: using this widget you can make numberbox, passportbox and so on.

> And don't tell me I should wait for XForms or something... As I know xforms specs doesn't supporting such things. In current realization of xforms <xforms:input> element is binding over <html:input> element like <xul:textbox>. Threafore you should provide supporting regexp for <html:input> element. It means specs of <html:input> element should be enlarged.

Alex, probably it's good way to implement typified input boxes :).

I tend to agree with Neil in that we shouldn't disable input while filling in the field. With Web Forms 2.0, text inputs will have a pattern attribute, so it should be trivial to extend <xul:textbox/> to pass on a pattern attribute down to the anonymous input.

(In reply to comment #1) > I can't see this happening without help from Editor - specifically, some way of > telling editor to abort the edit that just occurred. Otherwise every time you > need to "correct" the input you lose the regular undo, which is unreasonable. That's pretty easy to do since it's possible to prevenDefault() a keypress BEFORE it is handled by the editor... In that case, the TransactionManager remains out of the loop and the undo/redo stacks too. I'll post a patch in the next minutes, tested and working fine including wrt undo/redo.

This patch should be enough. As I said about it's undo/redo-friendly. I tested it with a <textbox filter="[a-z]"/> and it works fine. Did not test other flavors of textbox but since they all inherit from the base textbox, it should be straightforward. Neil, can you review please ?

Comment on attachment 426476 [details] [diff] [review] proposed fix for a filter attribute on XUL textbox >+ if (event.isChar && this.hasAttribute("filter")) { >+ try { >+ var filter = this.getAttribute("filter"); >+ if (!this.mFilter || this.mFilter.source != filter) >+ this.mFilter = new RegExp(filter, "g"); If the filter is only applied to characters, why is the user required to specify a full regular expression? I think that only makes for wrong expectations - it should be filter="a-zA-Z" and the code should construct a character class itself (or a negative character class if necessary). Also, RegExp.source isn't always identical to the string the regexp was compiled from - see new |new RegExp("foo/bar").source|. >+ if (String.fromCharCode(event.charCode).replace(this.mFilter, "")) { I think a better condition would be |!this.mFilter.test(String.fromCharCode(event.charCode))| keypress event isn't the only way to enter data into a text field. Pasting from clipboard and drag&drop are others that come to mind, you would need to filter the text there as well.

Comment on attachment 426476 [details] [diff] [review] proposed fix for a filter attribute on XUL textbox Those are some good points. Other things I noticed: >+ <property name="filter" onget="return this.getAttribute('filter') || '';" [Currently XUL getAttribute returns "" when hasAttribute returns false. Apparently this actually matches the DOM spec!] >+ <handler event="keypress" phase="capturing"> Is capturing necessary to process the events before the editor? I can't remember whether the editor uses the system event phase or not. >+ if (event.isChar && this.hasAttribute("filter")) { >+ try { >+ var filter = this.getAttribute("filter"); Does this do the right thing when the filter is the empty string? >+ this.mFilter = new RegExp(filter, "g"); Why the "g"? >+ if (String.fromCharCode(event.charCode).replace(this.mFilter, "")) { Or you could just use the (string, string) version of replace.

We can make it work with HTML 5 pattern validation later. :-) Though I would recommend changing the property name to "pattern" for forwards-compatibility. Also, HTML 5 uses /^(pattern)$/. The closer we can reflect HTML 5's current spec, the less textbox users will have to work when we adopt native pattern validation. Also, Wladimir pointed out this needs to cover pasting... would that be covered by the change event instead? I'm particularly wondering about the styling of the control, and how other elements and scripts might detect that this control is in an invalid state.

I'm not sure if this bug needs any core editor patches...

Daniel, up for a new patch?