feat: only install polyfill if there is no native support (#447)

[gruhn]

• feat: only install polyfill if there is no native support

• Modified gitignore to ignore vitepress cache and dist

[github-actions]

PR Preview Action v1.4.7
🚀 Deployed preview to https://gruhn.github.io/vue-qrcode-reader/pr-preview/pr-449/
on branch gh-pages at 2024-09-02 11:39 UTC

[cloudflare-workers-and-pages]

Deploying vue-qrcode-reader with    Cloudflare Pages

Latest commit:	a5a0a2a
Status:	✅  Deploy successful!
Preview URL:	https://5d0fcc19.vue-qrcode-reader.pages.dev
Branch Preview URL:	https://detector-polyfill-on-demand.vue-qrcode-reader.pages.dev

View logs

[gruhn]

@pastc it appears that Blob inputs to BarcodeDetector.detect are still not supported (at least) in Chrome on macOS. See this demo deployment:

https://53815a69.vue-qrcode-reader.pages.dev/demos/DragDrop.html

So this breaks QrcodeDropZone and QrcodeCapture. But can you confirm that QrcodeStream works? I only have devices without native BarcodeDetector support except a Mac (but that one doesn't have a camera).

[pastc]

@gruhn I tested the demo on the link that you gave me on a macbook air on chrome and it worked fine. all QrcodeDropZone, QrcodeCapture, and QrcodeStream.

[gruhn]

Hmm, that's odd. I just checked on my Mac I have at work (which both has a camera and native BarcodeDetector support). I can confirm that QrcodeStream works but for QrcodeDropZone and QrcodeCapture I see the same error. Can you check your console? If you turn on verbose logging in Chrome DevTools, it should log one of these messages, once you upload/drop a file:

[vue-qrcode-reader] BarcodeDetector not available: will use polyfill.

[vue-qrcode-reader] BarcodeDetector available: will use native API.

Either way, its probably ok to always use the polyfill for QrcodeDropZone / QrcodeCapture and use it on demand for QrcodeStream.

[pastc]

[pastc]

I don't know why it isn't working on your macbook.

[github-actions]

🎉 This PR is included in version 5.5.8 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[wosiwq]

@gruhn I think we need to check if the window.BarcodeDetector object supports formats by calling window.BarcodeDetector.getSupportedFormats() in the setScanningFormats method.

I'm running into a problem where some of the application's built-in browser, they have window.BarcodeDetector objects, but window.BarcodeDetector.getSupportedFormats() returns []

[gruhn]

Ok, that’s annoying. I think we should probably revert this change then. I mean we could detect this particular situation and take that into account when applying the polyfill, but who knows which other device/OS/browser combos are problematic.

[Sec-ant]

Ok, that’s annoying. I think we should probably revert this change then.

Happened to notice this issue, it's probably better to provide a boolean prop (like native) to let the user decide whether to use the platform-native barcode detection API, and default to false for compatibility and out-of-box experience.

[wosiwq]

Happened to notice this issue, it's probably better to provide a boolean prop (like native) to let the user decide whether to use the platform-native barcode detection API, and default to false for compatibility and out-of-box experience.

I think providing a prop for the user to choose from is a good idea. Maybe we could also compare the formats passed in by setScanningFormats with the list of window.BarcodeDetector.getSupportedFormats() to more intelligently toggle the value of the native?

[gruhn]

Happened to notice this issue, it's probably better to provide a boolean prop (like native) to let the user decide whether to use the platform-native barcode detection API, and default to false for compatibility and out-of-box experience.

I'm worried that this has a hidden cost. There might be a ton of random device/OS/browser combos where the native API is not quite working as expected. If a native prop is available, users can work around that a la:

if (edgeCase1) {
  setNativeProp(true)
} else if (edgeCase2) {
  setNativeProp(false)
} else { 
  ... 
}

But then users are less likely to open an issue here and share that knowledge. Thus, everyone is left to re-discover these issues by themselves. On the other hand, if users open an issue, we can at least try to find a solution, that fixes the problem for everyone.

Maybe we could also compare the formats passed in by setScanningFormats with the list of window.BarcodeDetector.getSupportedFormats()

I'd prefer this approach then.