Barcode scans not arriving in the browser on an Android handheld: causes and fixes

How a scan gets into the web app: keystrokes or intent

What the built-in scanner of a rugged handheld reads is usually passed on to apps by a scanning service from the device maker – DataWedge on Zebra devices. DataWedge works with profiles: a profile is associated with one or more apps and applies whenever one of them is in the foreground; each app belongs to one profile at most. Apps without a profile of their own get the default profile, Profile0. The profile also defines how the scan is passed on – for the browser, two outputs matter:

• Keystroke output (“keyboard wedge”)

  The scanning service types the code as if someone were pressing the keys – into whichever field has focus. The browser passes this input on to the web page like any other keyboard input. This is how a scan arrives in the stock browser.

• Intent output

  The scan is sent as an Android intent to an app that receives it with its own code – meant for native apps and for browsers with their own scanner integration. A web page in the stock browser cannot receive an intent: the scanner reads the code, but nothing arrives in the form.

Devices from other makers, such as Honeywell, have their own scanning services with their own settings; the device manual shows where to find them. The examples on this page use the DataWedge settings as documented by Zebra.

Troubleshooting: causes and fixes

A quick test first: in a simple text app, such as a notes app, tap an input field and scan. If the code appears there, the scanner and keystroke output work – so the cause lies in the browser app’s profile or in the web app. If it does not appear there either, check the scanner itself first: whether DataWedge is enabled, whether the barcode type is enabled among the decoders, and whether another app is holding the scanner – according to Zebra, only one app at a time can control the scanning hardware.

• No suitable profile for the browser

  If the browser app is not associated with a profile, Profile0 applies. If it is disabled, the device does not scan in the browser at all; if it has no keystroke output, the scanner reads but the data never reaches the app – exactly the situation Zebra describes. Fix: create and enable a profile in DataWedge (“Profile enabled”), add the browser app under “Associated apps” with all activities (the asterisk), and enable “Barcode Input” and “Keystroke Output” – or set up Profile0 accordingly. If the web app runs in several browsers, each one needs the association. The browser app must also not be on the list of apps in which DataWedge is disabled (Disabled App List).

• The scan goes out as an intent

  If the browser’s profile uses intent output instead of keystroke output, DataWedge sends the scan as an Android intent – which only an app with its own code can receive, not a web page. Fix: turn on keystroke output for the browser. Intent output is the right choice for native apps and for browsers that receive scans themselves.

• No input field has focus

  Keystroke output types wherever the cursor is. After a page loads, a field only has focus if the web app sets it or someone taps the field; otherwise the scan goes nowhere. If it lands in the wrong field, another field has focus – for example because an appended Tab moved it on. Fix in the web app: give the scan field the autofocus attribute and set the focus back with focus() after each submission.

• Characters go missing or arrive out of order

  If the code arrives faster than the app can accept it, characters can get lost. DataWedge’s keystroke output has a delay after each character for this (“Inter-character delay”, 0 ms by default): Zebra recommends raising it in steps of 100 ms until the errors stop, up to 1000 ms – which can slow the app down. With “Multi-byte character delay”, the delay applies only to multi-byte characters – according to Zebra, Unicode and multi-byte characters can cause problems when sent to the Android browser. If Enter arrives before the last characters, the delay before key events (“Key event delay”) helps: text and key events travel separately and can overtake each other.

• No Enter or Tab after the scan

  Some web apps only take the code on Enter – Enter in a text field can submit a form – or expect Tab to move to the next field. Fix: enable Basic Data Formatting in the profile and turn on “Send ENTER key” or “Send TAB key” there; DataWedge then appends Enter or Tab to the code. If every scan should move on to the next field of a web page with Enter or Tab, Zebra also recommends showing DataWedge’s own keyboard (an option of keystroke output) on Android 10 and later.

• The on-screen keyboard gets in the way

  On Android 10 and later, the default keyboard briefly disappears during a scan and comes back afterwards, because DataWedge delivers the data through its own input method. To keep it from appearing at all during a scanning session, Zebra recommends DataWedge’s own keyboard here too. In the web app, the inputmode="none" attribute tells the browser that a field needs no on-screen keyboard – a good fit for fields that are only scanned; test it on the device first.

• The web app listens to individual key presses

  Some web apps assemble the scan from individual keyboard events – with keydown or the deprecated keypress – instead of reading the field’s value. Whether every character arrives as a key press then depends on the output: from Android 10, DataWedge delivers through its own input method, and it sends printable characters explicitly as key events with the “Send Characters as Events” option. Reading the field’s value on the input event or on Enter is more robust. If the web app cannot be changed, “Send Characters as Events” is worth a try.

The options: from the stock browser to a kiosk browser

• Stock browser with keystroke output

  The obvious way without extra software: a scanner profile for the browser app with keystroke output, Enter or Tab as needed and, if necessary, a delay after each character. DataWedge settings can be exported and distributed to other devices through an MDM. Limits: the web app depends on focus and keyboard input and cannot control the scanner. An MDM can lock the device to one app in lock task mode (to any app from Android 9); whether the browser can be limited to certain sites depends on the browser.

• Adapt the web app to the scanner

  If you develop the web app yourself, you can make it robust against scanner settings: autofocus on the scan field, focus back after each submission, read the value on the input event or on Enter rather than from individual key presses, inputmode="none" for scan-only fields. This works whatever the device maker, as long as the scanner outputs keystrokes. It needs access to the web app’s code – often not available for bought-in software.

• Native app or your own WebView app

  An Android app receives the scan via intent with its own code and can also control the scanner, for example with a soft trigger. An existing web app can be embedded in your own app with Android WebView, which passes scans to the page by script. For calls from the page into the app, Android recommends addWebMessageListener with allowed origins, and the older addJavascriptInterface() only if you wrote all the content in the WebView. The price: Android development, maintenance, signing and distribution of the app.

• Kiosk browser with scanner integration

  A browser for rugged handhelds that receives the scan itself – via intent or the device maker’s scanner API – and types it into the focused field; web apps that read the field’s value then usually need no changes. Depending on the product, kiosk mode, a list of allowed sites and configuration through an MDM come with it. Several vendors offer such browsers; a factual comparison with well-known products is on the Industrial Kiosk Browser product page.

Not to be confused: terminal emulation is meant for text-based host applications over Telnet, 5250, 3270 or VT, not for web apps. If you still run such applications, you need a terminal emulator for them; a web browser alone – Industrial Kiosk Browser included – does not replace it.

Industrial Kiosk Browser: a kiosk browser with scanner integration by ICT Baden

Industrial Kiosk Browser is our kiosk browser for rugged Android devices with Android 8.0 or later, based on Android WebView. It receives scans itself instead of relying on keystroke output: on Zebra devices it creates its own DataWedge profile “Industrial Kiosk Browser” on start – intent output on, keystroke output off – and leaves the decoder settings alone. On Honeywell devices it uses the intent API of the Data Collection Service, on other devices any scanner app that sends scans to the browser via intent.

Industrial Kiosk Browser writes the scan as a whole into the focused input field – also inside shadow DOM and same-origin iframes – and fires input and change events, so web apps built with React or Vue pick up the value too. By default, Enter follows as a real key press; Tab, both or nothing can be set in the configuration (scanner.terminator) or per page with a meta tag such as <meta http-equiv="scanner" content="Enable,AutoTab"> for Tab instead of Enter. Web apps that read the field’s value – on the input or change event or on Enter – work without changes; a web app that assembles the scan from individual key presses should listen to the industrialkioskbrowser:scan event instead. If no text field has focus, nothing is written into the form and no Enter or Tab is sent – the scan event still reaches the page.

• For web developers

  The cancellable industrialkioskbrowser:scan event delivers the code, symbology and source before anything is written into the field; with preventDefault() the page handles the scan itself. The window.IndustrialKioskBrowser JavaScript API triggers a scan with a soft trigger (IndustrialKioskBrowser.scanner.trigger()), turns the scanner off and on, plays tones, vibrates and shows messages – on allowed hosts only, with a recent Android System WebView.

• Kiosk mode

  Hide toolbar and system bars, hide the exit or protect it with a password; lock task mode as a dedicated device (device owner).

• URL allow list

  With an allow list, the browser only opens pages of allowed hosts and their subdomains; main-frame navigations and form posts to other hosts are stopped before they load.

• On-screen keyboard on demand

  Optionally, the keyboard does not appear when a field is tapped, only via the keyboard button or a key.

• Configuration through your MDM

  One JSON file – as a managed configuration from any Android Enterprise EMM, as a file or via StageNow – the same for many devices.

Honestly: Industrial Kiosk Browser is a pre-release (0.x); settings, JSON format and JavaScript API may still change. The Honeywell integration follows the vendor’s documented intent API and has not been verified on a Honeywell device yet; Android 8 to 10 is covered by unit tests only. Real kiosk mode (lock task) needs an EMM in dedicated device mode (device owner); without it, the browser only hides the exit. An empty allow list allows every host. The JavaScript API is not available on servers with a non-default port – scans, the scan event and the meta tags still work there. Releases up to 0.6.x were still called Pforte, before that EnterpriseBrowser; version 0.7.0 brings the new name, and Android treats it as a new app – there is no in-place update; roll out the configuration again and remove the old app. Until the signing key for the new package name is set up, releases contain the SBOM and checksums but no APK. Industrial Kiosk Browser is a web browser, not a terminal emulator, and does not support the specific interfaces and configuration files of other industrial browsers. It is free of charge under the MIT licence. The download follows with the public release.

Our product

Industrial Kiosk Browser – Kiosk browser for rugged Android devices

Scans from DataWedge, Honeywell or any scanner app via intent go straight into the focused field, followed by Enter by default or by Tab – with kiosk mode, URL allow list and configuration through your MDM; Android 8.0 or later.

Status: Available · Coming soon

More about Industrial Kiosk Browser Comparison with other industrial browsers

The options compared

“Depends on the product” and “depends on the implementation”: features and prices differ. Terminal emulation is left out on purpose – it is meant for host applications over Telnet, 5250, 3270 or VT, not for web apps. Industrial Kiosk Browser is a pre-release (0.x); its Honeywell integration has not yet been verified on a device.

Which option fits when?

• The scan is missing only in the browser, other apps get it

  Check the browser app’s profile: enabled, associated, with “Barcode Input” and “Keystroke Output” switched on.

• The code arrives, but without Enter or in the wrong field

  Append Enter or Tab with Basic Data Formatting, and set the focus on the scan field in the web app.

• Characters go missing in long codes

  Raise the delay after each character in steps of 100 ms.

• You develop the web app yourself

  Make the web app robust – focus, input event, Enter – and the scanner’s keystroke output is enough.

• Many devices, one web app, the device should be locked down

  A kiosk browser with scanner integration, for example Industrial Kiosk Browser – currently a pre-release (0.x), locked down as a dedicated device (device owner).

• The application needs device features a browser does not offer

  A native app or your own app with WebView.

• Host applications over Telnet, 5250 or 3270

  A terminal emulator – a web browser alone does not speak these protocols.