Discussion: `navigator.share.qrCode`

Question

Discussion: `navigator.share.qrCode`

Closed this issue 2 years ago · 19 comments

Chromium has added an option to get a QR code for the current URL via the URL bar. It would probably be useful to expose this feature as a browser API on all form factors to let developers add QR code generation as a feature to their apps. A possible location could be…

const blob = navigator.share.qrCode('text', {
  format: 'image/png', // optional
  size: 512, // optional
});

This would return a QR code image blob that developers could then show according to their own needs. I believe it could be a synchronous function, since no permission would be required.

(Original idea via this tweet.)

Answer 1 · 2021-05-29T01:29:09.000Z

It wouldn't be ideal to have a particular type of share specifically for QR codes, but are QR codes identifiable as a media type? I've never looked at how they are created/structured or if they are even standardized, but maybe just sharing as files could work?

I think it goes roughly blob with media type -> QR code representation.

Answer 2 · 2021-05-31T06:35:55.000Z

It wouldn't be ideal to have a particular type of share specifically for QR codes […]

Something else that's quite common is to share a PDF version of the page or (probably less common) a web archive version of the page (example link). So QR code would not need to be the only option. Maybe navigator.shareAs() then?

[A]re QR codes identifiable as a media type? I've never looked at how they are created/structured or if they are even standardized […]

They are to become an ISO standard, but I don't think they will have a media type.

[M]aybe just sharing as files could work?

Unsure about the plural here.

Answer 3 · 2021-05-31T07:07:12.000Z

Isn't this just part of the page/browser UI (I.e., standard browser share stuff)? For installed PWAs then, maybe what we actually want is just:

// Share this top-level browsing context
navigator.share();

Which would bring up the share "default" share for the page? On iOS/Android, then the use can share as PDF, Web Archive, or whatever new thing thing gets added to share at the OS level in the future.

True, but the idea here would be to let the developer do something with the created QR code, PDF, etc., and not just expose the system UI.

/me shakes first!!!, "USD$70 to view a standard! Curse you IIIISSSOOO!!!" 😆

For me it's CHF 58 for whatever reason (I'm based in € Europe). But /me shakes fist, too…

The plurals are handled by the OS share... if it only gets one thing, then it knows what UI to show. For example, IIRC, this is already supported for images (single image VS multiple images get different share UIs).

Ah, gotcha.

Answer 4 · 2021-07-01T00:16:49.000Z

It could be a good idea to reconsider #180 if we want this.

Answer 5 · 2021-07-01T03:45:20.000Z

I still think this should just be a "file"... or at least, we should see if it can't be a file.

Answer 6 · 2021-07-01T06:49:05.000Z

The original idea from this Issue was to tap into browser-facilitated share methods, like Chrome's Create QR code for this Page, so people don't need to pull in a QR code generation library but could use the browser's.

Answer 7 · 2021-07-01T07:58:09.000Z

Ah, lol! sorry!!! I had misunderstood as I've not seen this before. Just found it in Chrome. That's super cool!!!!! :D

So, maybe something like

navigator.share({ url: "other thing", as: "qr" });
navigator.share({ text: "some text", as: "qr" });

Answer 8 · 2021-07-01T08:07:36.000Z

Ah, lol! sorry!!! I had misunderstood as I've not seen this before. Just found it in Chrome. That's super cool!!!!! :D

My bad, I could have added a help link to the initial post instead of just describing the feature and assuming people are aware.

So, maybe something like

navigator.share({ url: "other thing", as: "qr" });

url should probably be a URL:

navigator.share({ url: location.href, as: "qr" });

navigator.share({ text: "some text", as: "qr" });

Yeah, it's a hidden power-feature that the text can be changed. So +1 to exposing it!

Additional options could be as: "mhtml" (a feature of the File > Save As dialog) and as: "pdf" (a feature of the File > Print… dialog). These would silently assume the url is the URL of the current page. Would this work?

Answer 9 · 2021-07-01T08:17:40.000Z

I like where this is going :) it has the nice quality that it has fallback model.

Answer 10 · 2021-07-01T08:52:54.000Z

How could this be feature detected?

Answer 11 · 2021-07-01T08:57:14.000Z

How could this be feature detected?

Maybe by extending navigator.canShare()?

Answer 12 · 2021-07-01T09:21:00.000Z

canShare() itself has a problem where a new field will be always ignored by an older implementation. I would prefer an existence check rather than complicating already-problematic one.

Answer 13 · 2021-07-01T10:20:07.000Z

Should this be feature detectable? It's aspirational.

Answer 14 · 2021-07-01T10:22:43.000Z

Should this be feature detectable?

Well, it would be confusing to request a qr code and then get a plain share dialog?

Answer 15 · 2021-07-01T10:32:09.000Z

could be... but I think that's a UX thing. Like the UI could allow the user to just switch it to normal text/url/whatever.

Answer 16 · 2021-07-01T10:32:43.000Z

(and the other way around too... like, I could share a URL and have something in the UI show it as a QR code)

Answer 17 · 2021-07-01T10:34:59.000Z

That would be cool and would probably not require adding any API.

Answer 18 · 2022-06-07T05:14:15.000Z

Closing for now, as it seems possible to simply share the URL and have the share target or user agent present it as a QR code.

Answer 19 · 2023-11-14T19:50:10.000Z

Is there a way to "tell" the user-agent that we prefer sharing as a QR?
It's akin to Chrome's own functionality: