fix: WebLN QR fallback for anon users

[Soxasora]

Description

Fixes #1758
When a WebLN wallet request fails (eg. cancelling a transaction) it can't be re-requested until next reload, throwing an error and prompting an invoice retry with QR that fails if the user is not logged in.

This fix checks for 'me' on useWalletPayment, throwing a new AnonWalletError that can be caught during QR fallback to show both the WebLN client and the QR payment

Screenshots

Screen.Recording.2025-02-10.at.09.45.51.mov

Additional Context

Fix specifically applied for WebLN

Checklist

Are your changes backwards compatible? Please answer below:
Yes, only affects WebLN wallet

On a scale of 1-10 how well and how have you QA'd this change and any features it might affect? Please answer below:
7, more testing

For frontend changes: Tested on mobile, light and dark mode? Please answer below:
n/a

Did you introduce any new environment variables? If so, call them out explicitly here:
No

[ekzyis]

Mhh, it's a bit hard to understand the implications of these changes. For example, I am worried if the priority of the WebLN wallet makes a difference for these changes here.

I think a better way to fix #1758 is to make useWalletPayment aware of if we're logged in or not.

If we're not logged in, try to pay with WebLN if available (typeof window.webln !== 'undefined') and ignore the rest of the code. That it currently might not ignore it for anons because WebLN might have been enabled (wallets.length > 0) is the bug we should fix imo. 99% of our code for payments assumes you're logged in and thus that anons will never hit that code.

What anons can do in comparison to stackers is very limited (no sender and receiver fallbacks, no retries etc.) so I suspect if we (continue to) handle anons during payments immediately, it will be much easier to implement, maintain, read etc.

[Soxasora]

Thanks a lot for the correct redirection, now we call WebLN's sendPayment when QR shows up! But only if we reached QR stage because of AnonWalletError that gets thrown by useWalletPayment if the user attempting to pay is Anon.

I think it's the correct behavior and gives a choice, if anything we could 'await' for sendPayment to throw an error to show the QR if we ever change idea.
Thanks again ^^

[ekzyis]

You fixed the main issue in #1758:

However, if the WebLN prompt was canceled, we won't show a QR code because anon can't retry invoices.

But we can do better and always allow WebLN payments for anon, even if the wallet wasn't enabled while logged in:

I think anons should be able to use WebLN but that we only try it if it was enabled while signed in is weird.

So I suggested to change the order in which we check for errors.

Other than that, this is approved!

[ekzyis]

Approving this because this is more than enough to fix #1758, nice work!

But for the sake of a complete review, I want to mention that I noticed it would be nice if WebLN errors showed up in the QR code. I did not test, but I think that is not the case currently. I also noticed that the other throw statements should probably also use WalletError now. Since it's a small innocent change afaict, I went ahead and did that in ba93d34.

But these were nitpicks, mostly unrelated to the bug described in #1758 and not really important whatsoever so don't worry about not noticing them; just mentioning them to "open your third eye" regarding details even more (lol). We can do the WebLN<>QR error thing when we actually care about it if ever.

edit:

I see that you already considered this in #1858 (comment):

if anything we could 'await' for sendPayment to throw an error to show the QR if we ever change idea.

[Soxasora]

I noticed it would be nice if WebLN errors showed up in the QR code. I did not test, but I think that is not the case currently.

Ah yes, that was the case before pivoting to QR and WebLN together, catching the error during retry would show it in QR.

I agree with

We can do the WebLN<>QR error thing when we actually care about it if ever.

I went ahead and did that in ba93d34.
just mentioning them to "open your third eye" regarding details even more (lol)

:D I think I need to let go some of my conservativeness when touching the code, thanks a lot for the review ek ^^