Download button does nothing in in-app browsers (for example WhatsApp...)

On the completed submission page (/s/:slug after signing), the Download button is inert when the page is opened inside a mobile in app browser. The user taps it, the button switches to its loading state, and nothing else happens — no file, no error.

This affects any flow where the signing link is delivered through a messaging app rather than email, since those apps open links in their own WebView by default.

Potential cause

app/javascript/elements/download_button.js never navigates to the document URL. It fetches the file and hands the browser a blob: URL through a synthetic anchor click:

const blobUrl = URL.createObjectURL(await resp.blob())
const link = document.createElement('a')
link.href = blobUrl
link.setAttribute('download', decodeURI(url.split('/').pop()))
link.click()
URL.revokeObjectURL(blobUrl)

Android WebView (and the iOS equivalent used by these apps) does not forward blob: downloads to the system download manager. The click is silently dropped. This is a long-standing WebView limitation, not something the page can detect or work around from inside the sandbox — target="_blank", intent:// and x-safari-https:// are all either ignored or blocked in this context.

The existing downloadSafariIos branch shows the same class of problem was already hit on iOS (see 78fb93f and 5a96f4f), but the workaround there still relies on blob: URLs, so it does not help in a WebView.

Suggested fix

GET /s/:slug/documents already returns plain HTTPS URLs — ActiveStorage proxy paths, which every browser including WebViews handles natively. A direct navigation is enough, and the proxy controller already honours a disposition parameter:

send_blob_stream blob, disposition: params[:disposition]

So for the common single-document case, the blob round-trip can be skipped entirely:

if (urls.length === 1) {
  window.location.href = `${urls[0]}?disposition=attachment`
  return
}

This works in every browser, removes one full fetch of the file into memory (relevant for large PDFs on mobile), and would likely allow the iOS-specific branch to be dropped as well.

This would be applied only for the single-document case. In the multi-document case, the current behavior would not change.

I can open a PR if that can help you and if you think it's the right approach.