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

Compatibility issue between ui-grid, ng-pattern-restrict and IE11 #28

Closed mathiasdose closed 9 years ago

mathiasdose commented 9 years ago

I've got a compatibility issue between ui-grid (https://github.com/angular-ui/ui-grid), ng-pattern-restrict and IE11.

The problem is that when trying to edit a cell, which when in edit mode is an input element with ng-pattern-restrict attached to it (using custom template), the code below will cause the cell to immediately close again.

notThrows(function () { input.setSelectionRange(0, 0); })

I've made two plunkers to make it easier to grasp the problem, here is a plunker with the problem: http://plnkr.co/edit/ZUxXAMMqRpQ1ksTUcI2u?p=preview

If you target a cell on the last row and the row isn't completely visible as illustrated on the picture below, and then try to write any number (my demo regexp only allows numbers), you'll see that the cell stutters and don't enter edit mode. If you want to see how it should look like just edit any other cell on any other row. screen shot 2015-09-03 at 12 35 44

I have identified the problem to the code snippet pasted above, here is a plunker using a typeOf check instead, which seems to solve the problem at least for this case: http://plnkr.co/edit/4BeVS7wcTST5Swpx7yQl?p=preview

I saw that in #24 you touch this part of the code, and that change would maybe fix my issue. How is that pull request coming along?

AlphaGit commented 9 years ago

Hi! First of all, thank you very much for this great detailed bug report. I really appreciate the effort you put into it.

On the code change, it's been pretty much stuck on webdrivers giving me hell on non-text inputs, which really impedes my ability to check browser compatibility. I've been waiting on some colleague's input on Sikuli, which may help in overcoming that, but CI integration is going to be a whole other subject.

I think the best option might be to drop some browsers off the compatibility matrix, setup a bunch of VMs (Linux, Windows, Mac) with a bunch of browsers (FF, IE, Chrome, Safari at the very least) and test it out manually. I'll see if I can setup something over the weekend and at least get these bugs out of the way.

Any ideas would be appreciated.

mathiasdose commented 9 years ago

Thanks for quick reply!

I've seen https://saucelabs.com/home been used for CI testing cross browsers, it's free for open source projects also.

AlphaGit commented 9 years ago

Yes, that exactly what I've been experimenting with. This is one of the tests, as an example, with the new code: https://saucelabs.com/beta/tests/798a31ea6064498db7f7c418cecda0d1

AlphaGit commented 9 years ago

@mathiasdose Hi! The problem was effectively fixed with the changed you mentioned. Those had been already incorporated in the master branch, on the commit cae78314fe1d6529166a472c46bf101153e6a42c.

Thanks for the Plunkr, it made it really easy to verify!

mathiasdose commented 9 years ago

@AlphaGit Awesome, thanks for the help!

mathiasdose commented 9 years ago

@AlphaGit How long can I expect before I see the update on bower?

AlphaGit commented 9 years ago

@mathiasdose I was expecting to wrap up some other tasks before releasing the new version. It may take a while (a few days... weeks?). These are the tasks I wanted to finish.

If you need it right now, I'd suggest you point bower to the particular hash of the latest commit right now, or to master directly if you want to get the latest whenever it is updated.

mathiasdose commented 9 years ago

@AlphaGit Okey I'll point it to the latest commit.

AlphaGit commented 9 years ago

@mathiasdose Sorry to bother you again, but I just released 0.2.0 with the latest changes and I thought you'd like to know. ;)