Блог

В нашем магазине есть устройство сканирования для своего веб-приложения, где мы обрабатываем ввод устройства с помощью события нажатия клавиш jQuery. Это работает нормально, за исключением того, что теперь у всех старых iPhone (4,5,6), похоже, возникают проблемы с обработкой события нажатия клавиш при обновлении. Что я замечаю, так это знак , а затем клавиша ввода запускается почти одновременно, но большинство браузеров обрабатывают это правильно…

Обработка запускается, когда пользователь нажимает клавишу ввода или сканер нажимает клавишу , т.Е.:

 e.which = 13 || e.which = 187
  

Когда я прохожу через отладчик SAFARI, значение селектора jQuery пустое. Когда val () селектора имеет фактический отсканированный штрих-код UPC, iPhone передает события нажатия клавиш, и запускается горячая клавиша iOS keyboard. Поскольку у нас есть настройка для запуска обработки focusout, пользователь может нажать «Готово» на своем iPhone, вернуть фокус в селектор и отсканировать следующий элемент.

Вряд ли это жизнеспособное решение, поскольку наши пользователи должны иметь возможность непрерывно сканировать на своих iPhone. Есть предложения?

Вот фрагмент кода:

 $("input[name='SCAN']").on("keydown",function(e) {
         var processRegex = /^([0-9]{7,14} ?)$/;
        //on SCAN (last character is a ' /=') field - reload detail section
         if (e.which == 13 || e.which == 187){
                scan_val = $.trim($("[name='SCAN']").val());
                if(processRegex.test(scan_val)){               
                  Handle_Scan(scan_val); //ajax processing function         
                }
                else
                    $("[name='SCAN']").val('').focus();

            return false;
        }

            return true;
    }); 
  

Это как если бы значение элемента DOM передавало regX, но keydown EventListener преждевременно возвращает значение обратно, как если бы оно не дошло до последнего захвата ключа, возможно, указывая на неправильный адрес памяти. Это не было проблемой до обновления iOS 10! Интересно, чем этот движок javascript отличается от предыдущих версий?

Мне пришлось обернуть всю логику обработки с помощью a setTimeout(function(){ //handle_scan},250); , чтобы позволить обработчику событий завершить захват последнего keydown события и вернуть управление DOM, чтобы вызывающий мог затем выполнить функцию.

Очевидно, что этого не должно произойти. Итак, что меня так смущает, так это то, что кажется, что движок javascript либо слишком быстрый, либо прослушиватель событий слишком медленный.

Я подумал, что это может иметь какое-то отношение к использованию keydown instead keyup поскольку вы можете непрерывно запускать обработчик событий, удерживая клавишу нажатой, поскольку сканер выполняет это действие за долю миллисекунды, но не имело значения, какой обработчик я использовал. Я keydown решил, что это вернет управление вызывающему абоненту быстрее, надеясь, что обходной путь не понадобится.

Возможно, механизм javascript считывает значение, пока прослушиватель событий опрашивает следующее аппаратное прерывание?