Leading minus not working in input (catch-all regexes and inputs type=number)

[schoofseggl]

I use the following pattern for ng-pattern-restrict (as an example)

"^[+\-]?([1-3])*$"

It is applied to a input type=number field. When using ng-pattern-restrict, I am not able to start typing numbers with leading + or - signs. But I am in fact able to first type "2", and then insert a "-" before the "2".

For some other reasons I cannot use an input type=text field.

regards

Andreas

[schoofseggl]

I need to add the information that even with the simple pattern "^.*$" ng-pattern-restrict makes it impossible to type a leading sign.

In the browser console I get the following error:

Uncaught DOMException: Failed to read the 'selectionStart' property from 'HTMLInputElement': The input element's type ('number') does not support selection.
    at getCaretPositionWithInputSelectionStart (http://localhost:9000/libs/ng-pattern-restrict/src/ng-pattern-restrict.js:40:31)
    at updateCurrentValue (http://localhost:9000/libs/ng-pattern-restrict/src/ng-pattern-restrict.js:137:29)
    at HTMLInputElement.genericEventHandler (http://localhost:9000/libs/ng-pattern-restrict/src/ng-pattern-restrict.js:159:15)
    at HTMLInputElement.dispatch (http://localhost:9000/libs/jquery/dist/jquery.js:4737:27)
    at HTMLInputElement.elemData.handle (http://localhost:9000/libs/jquery/dist/jquery.js:4549:28)

[AlphaGit]

Hi @schoofseggl! Thanks for the issue report.

Unfortunately, input type=numbers behave very weirdly and provide little feedback to the code that may result in these behaviors.

The problem you're experiencing with the plus/minus sign can be explained by the input having a bad value while you're in the middle of typing the number (since + or - are not valid numbers per se), and the browser just reports having an empty value and a bad input. (This is, if the browser even reports the bad input.)

The second problem, however, you should not be experiencing. The code does check for selectionStart being available and not throwing before it can use it, and so you should not be facing that exception. Would you mind to let me know which browser and browser version are you using? Maybe I can take a look at that.

Also, are you using the latest version of the library? If not, would you mind to let me know which version are you using?

Thanks!

[schoofseggl]

Hi @AlphaGit

Tested with Chrome "Version 55.0.2883.87 m (64-bit)" and ng-pattern-restrict version 0.2.2.

Regards

Andreas

[AlphaGit]

Thanks a lot! I'll take a look into that and report back to you.

[schoofseggl]

Just a side-remark: It would be helpful for me if there was a possibility to dynamically disable ng-pattern-restrict (e.g. I would do so for input type=number). Something like ng-pattern-restrict ng-pattern-restrict-inactive=true

In my case ng-pattern-restrict is used inside another directive and the input type can be configured from outside.

<my-input-ctrl type=number pattern="patternKey"> is rendered to something that contains <input type=number ng-pattern-restrict="patternValue">

Now for number fields I don't need to apply a pattern - as the browser is doing it for me - therefore I would like to use a pattern like ".*" - the problem is that even with this pattern input number fields are affected by the problem (the reason why I opened this request).

So I have to dynamically remove the whole ng-pattern-restrict directive in my custom directive which i find very hard to do dynamically in angular.

[AlphaGit]

Ah! Interesting. Thank you very much for the context of your use case -- I see why the obvious solutions are not possible here.

Let me give it some thought, maybe there's a new feature, like the one you suggested, that could help in this case.

[AlphaGit]

Hey @schoofseggl -- so, this is what I'm thinking so far.

At first, the idea of a turn-on/off switch for the directive sounded nice, but upon further thought, I am really not keen on that idea. Basically, I don't think it quite makes sense to have a directive that specifically works to achieve a function that you can turn off within that same directive. I'd think that in most situations, if you don't need to use the feature, you would be better off not using the directive. (Think of the ngValidation features which follows a similar approach: either you use it or you don't, but it's not planned to be taken in an out.)

My first thought if I was in your side would be to approach the dynamic compilation of the templates.

However, not all is lost! (And no, I wouldn't just come here to tell you that there's a lot of work ahead of you, hehe...). This that you said resonated with me:

therefore I would like to use a pattern like ".*" - the problem is that even with this pattern input number fields are affected by the problem

I don't think this is right. Using a pattern like /.*/ is meant to accept everything, but this directive is preventing input for you. I think we can call that a legitimate bug.

As for what causes the issue, I believe that it is consistent with your expected behavior. In the case of a type=number (or any type, for that matter), there's no possible input that wouldn't satisfy /.*, even when the input reports validity.badInput. I can definitely check for those.

I'll be submitting a fix very soon. Let me know if this addresses your situation.

[AlphaGit]

I just added special behavior for catch-all regexes. I think this should solve your problem. This code is already published in npm and bower, version 0.2.3, commit 2cc8f1851e4f3ee66f9e7480e1714e4eb75e89e5.

Let me know if you have any feedback about it, or if you still require some workarounds. I'd be glad to help.

[schoofseggl]

You're right, it sounds weird to use the directive and switch it off. I fully agree. But as you accepted the non-working ".*" pattern on input number fields as a bug, you saved me :). I will test it right now - Thx a lot

[schoofseggl]

I tested it, I can now user the .* pattern on input fields. Thanks a lot for your support!

I just noticed that I still get the exception on number fields with a different pattern (see below). If I understood you correctly you cannot work around it - but I can prevent it from happening because I will replace the pattern in my directive controller now :)

Uncaught DOMException: Failed to read the 'selectionStart' property from 'HTMLInputElement': The input element's type ('number') does not support selection.
    at eval (eval at evaluate (:117:21), <anonymous>:1:12)
    at getCaretPositionWithInputSelectionStart (http://localhost:9000/libs/ng-pattern-restrict/src/ng-pattern-restrict.js:41:13)
    at updateCurrentValue (http://localhost:9000/libs/ng-pattern-restrict/src/ng-pattern-restrict.js:138:29)
    at HTMLInputElement.genericEventHandler (http://localhost:9000/libs/ng-pattern-restrict/src/ng-pattern-restrict.js:165:15)
    at HTMLInputElement.dispatch (http://localhost:9000/libs/jquery/dist/jquery.js:4737:27)
    at HTMLInputElement.elemData.handle (http://localhost:9000/libs/jquery/dist/jquery.js:4549:28)

[AlphaGit]

Ah, thanks! That's definitely not right. I'll take a look at it. I'm glad it worked!