search

AlphaGit / ng-pattern-restrict

Allowing only certain inputs based on a regex pattern, for AngularJS
http://alphagit.github.io/ng-pattern-restrict/
MIT License
47 stars 32 forks source link

restriction is not working [opera] #13

Closed Mouvedia closed 9 years ago

Mouvedia commented 9 years ago

Using pattern="\d*" ng-pattern-restrict type="number" I can type letters in my input.

opera version 12.16 rev 1860 angular 1.3.5

AlphaGit commented 9 years ago

Tested with latest Opera up to date (26.0.1656.60), no problems so far. Opera 12 was released in 2011, I think it's acceptable to support. I'll downgrade my version and recheck.

AlphaGit commented 9 years ago

image

It actually seems to be a problem with the way that Opera handles invalid numeric input -- it seems not to be setting any way of detecting how we can tell that the input is invalid vs. when it is empty.

Will research a little more to see what I find.

AlphaGit commented 9 years ago

I've reached the point where for an input type=number, Opera will just tell me that the input is valid, no matter what I do to it. So I've reached out to StackOverflow in this question in hopes that there's a workaround that can be done for this.

Mouvedia commented 9 years ago

For the input type number validation, if you require ngModel you should be able to exploit the fact that the model is undefined unless it's valid.

AlphaGit commented 9 years ago

http://plnkr.co/edit/73w74TlGkw7inHdDtZAY?p=preview

(Embed link for Opera, since Opera 12 cannot handle Plunkr: http://embed.plnkr.co/73w74TlGkw7inHdDtZAY/preview)

That was a really good suggestion, I did however test it out and ngModel returns null both on the empty string and invalid input. Which is a problem, because we definitely want to support empty space.

Also, we're intending to stand before ngModel if it's present, because we're looking at the browser events directly. As such, I'm not 100% sure that we can rely on the value of ngModel.

In the stack overflow question someone proposed using:

element.focus();
document.execCommand("SelectAll");
window.getSelection().focusNode.selectionStart;

This has the same problems of destroying the user selection, but we are either in one of these situations:

I think this could be an acceptable approach. Will try it out and get back to you.

AlphaGit commented 9 years ago

@Mouvedia I believe it was you who provided the answer in SO -- if it was, thank you very much! The usage of the selection commands worked like a charm. I pushed the changes in this PR: #14, would you mind to check it out?

I tested in these browsers and works as expected:

This does not solve #12 though, so you'll still see the error and the caret being thrown at the end of the input in Chrome.

Mouvedia commented 9 years ago

It was me indeed ^^

line 105 is too restrictive. It might require some tests with other types like tel for example. Sorry for the delay, it's working fine on my side.

Concerning #12, seeing errors in my console bothered me. The fact that the caret doesn't keep its position is not a great loss. If I could I would have labeled 12 as a minor annoyance.

AlphaGit commented 9 years ago

Thanks! I've merged #14 and that should solve this problem! Thanks for coming back to this.

Closing this ticket.