Library randomly fires hallucinated "successful" scans

[mattmattmatt]

Describe the bug
When a Scanner mini-app is left open for a while, the underlying barcode detection library starts firing seemingly random "hallucinated" scans.

These scans are of BarcodeFormat value 12, aka RSS 14 bar codes. The decoding of those is handled in UPCEANReader.js as provided by the ZXing library.

Once a hallucinated code is fired (e.g. 201215783246180), it is that code (and not other random codes) that continue to fire. Different instances of the bug will fire different codes.

I have been unable to reproduce exactly when or why that happens, but once it does, only resetting the scanner/the underlying library stops the hallucinated scans. Even presenting a valid barcode/qr code to the camera will not be recognized, as the library is "busy" recognizing the hallucinated code.

To Reproduce
I wish I had a way to reproduce this reliably. Sometimes it happens ~30 secs into a scanner being left running, sometimes several minutes. Sometimes it does not happen at all.

Expected behavior
When no barcode is presented to the camera, result handlers do not fire.

Desktop (please complete the following information):

• OS: MacOS
• Browser Chrome
• Version 129

Additional context
I tried to see if others ran into this issue but did not find any reports.

This is how the library is instantiated in our React app:

  const codeReader = new BrowserMultiFormatReader(undefined, timeBetweenScansMs)
  codeReader.decodeFromVideoDevice(cameraId, videoRef.current, handleResult)

The described behavior is also present when passing a video element's id to the Reader, not a DOM element.

[opl-]

I'm currently consistently running into this a similar issue after scanning just a single GS1 DataBar. Using codeReader.decodeFromConstraints (which is also used by decodeFromVideoDevice).

The result passed to the callback contains a different timestamp from getResultTimestamp(), but getResultPoints() returns the same points.

Covering the camera to black it out results in no more non-error callbacks being returned until the camera is uncovered again, at which point the same text and points continue to be returned. (Edit: This is due to HybridBinarizer.getBlackRow() returning a NotFoundException, which is a pre-processing function called to obtain an argument then passed to the RSS 14 reader.)

Presenting another DataBar to the camera doesn't change the result, despite the decodeRow function receiving new data through the row argument.

Another edit: The reset() function never gets called, resulting in the possibleLeftPairs and possibleRightPairs state of RSS14Reader to never get cleaned up before the next decode attempt. Since iterating over the found possible pairs is always in order from first to last found, the first valid pair found will forever remain the one which gets returned, even if others were found in subsequent decode attempts.

Original ZXing library calls reset() after every decode attempt:

https://github.com/zxing/zxing/blob/2dfb2054af1e1872ac5354e6d8218931fb88e021/android/src/com/google/zxing/client/android/DecodeHandler.java#L76-L83

[opl-]

As Reader.reset() is a no-op in every reader other than RSS14Reader and RSSExpandedReader, I believe this issue only affects those two. (UPCAReader also implements it, but it calls a function on a reader for which reset is also a no-op.)