Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loosing characters in bound field when using Barcode scanner and IE #917

Open
HubertoKusters opened this issue Dec 19, 2018 · 5 comments
Open

Comments

@HubertoKusters
Copy link

HubertoKusters commented Dec 19, 2018

I'm submitting a bug report

  • Library Version:
    aurelia-framework@1.3.0

Please tell us about your environment:

  • Operating System:
    Windows 7/10

  • Node Version:
    v10.8.0

  • NPM Version:
    6.5.0

  • Aurelia CLI OR JSPM OR Webpack AND Version
    CLI 1.0.0-beta.7 (Webpack)

  • Browser:
    IE 11

  • Language:
    TypeScript 2.7.2

Current behavior:
We have an application that is to be used in our Distribution Centers.
It has only one bound inputfield. The workstations have a Barcode Scanner that is connected via USB and which behaves as a keyboard. The characters of the scanned barcode are send to the workstation as if they were typed in. The scanner is configured to emit a carriage return at the end of the input which triggers our business logic.
The scanner can be configured to have a delay per keystroke ranging from 0-50 ms.
In google chrome we have no error whatsoever, regardless of the delay.
In IE (11) however, we see missing characters at random locations.

We have used this setup in the past using Durandal (knockout) and never had a problem.
When we set the above mentioned delay to 50 ms, the input is received completely. This is however an unacceptable delay.

Expected/desired behavior:
We expect to receive all characters even with a 0 ms delay (like in Chrome).

  • What is the motivation / use case for changing the behavior?
    We first had a Durandal setup. But we want to upgrade to a modern framework and Aurelia is the logical choice.
@qmennens
Copy link

qmennens commented Dec 19, 2018

I would like to add additional information to this issue since I've also been working on the application mentioned by @HubertoKusters.

Strange thing here is that I created a new Aurelia application using the CLI and when first using it in IE with a barcode scanner I had no problem. But after closing IE and then again starting IE and opening the application the handling of the scan would be only partial like below:
image
PS: The barcode scanned should give number "00201711780529693686".

Now when I open de developer tools (F12) in IE and scan again the number is good. Then closing de developer tools and continue scanning all works as expected:
image

In this example I was using the "Symbol DS4308 Handheld Scanner" with a 0ms delay. As mentioned by Huberto this works fine in Chrome. We also had the problem using the HHP IT3800 barcode scanner which is an older model that does have delay (the default) between characters, but even then in IE we lose characters in between.

I'm also adding my test application in the hope that anyone is able to reproduce the issue and hopefully point us to a solution.
BarcodeScanner2.zip

Extra info on our IE version:
image

@bigopon
Copy link
Member

bigopon commented Jan 29, 2019

@HubertoKusters @qmennens Hi, may I know how this has been handled for you? Did you manage to find out the cause for this?

@HubertoKusters
Copy link
Author

Unfortunately we did not get any response until now. For now we have limited the application to be used with the Chrome-browser. However, this is not a solution and as such we are not sure if Aurelia is the way to go for us.

@bigopon
Copy link
Member

bigopon commented Jan 29, 2019

I see the frustration, I'm not sure how to reproduce this behavior and I'm not sure in which way it can be debugged. IE11 has quirks that are probably not in my awareness. I will try to simulate the scanner by repeatedly dispatching input and see if I can reproduce it on IE11.

@HubertoKusters
Copy link
Author

If you could shed some light on this, that would be great, Quirine has added a sample application in this thread. Maybe that could help. Also, it is very much possible that we made a design-error in the handler that just happens to work for Chrome by 'accident'. So, we keep an open mind on this.
TIA

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants