Admin link Blob PDF download silently fails in Shopify Mobile but works in mobile Chrome

We’re seeing a PDF download silently fail from an embedded page opened through an admin link extension in the Shopify mobile app.

The same flow works in desktop Chrome and standalone mobile Chrome. Inside Shopify Mobile, the embedded page reaches Download complete state, but no file is downloaded.

Admin link configuration

[[extensions]]
name = "Download PDF Invoice"
type = "admin_link"

[[extensions.targeting]]
target = "admin.order-details.action.link"
url = "/app/download-pdf"

The relative destination follows Shopify’s admin link documentation:

Download implementation

The destination page fetches a server-generated PDF and creates a Blob download:

const response = await fetch(pdfUrl);
const blob = await response.blob();
const blobUrl = URL.createObjectURL(blob);

const link = document.createElement("a");
link.href = blobUrl;
link.download = "1332 - Invoice.pdf";
document.body.appendChild(link);
link.click();
link.remove();

URL.revokeObjectURL(blobUrl);

This runs after the merchant taps the order-details admin link and the embedded destination page loads.

Steps to reproduce

  1. Add an admin link extension targeting admin.order-details.action.link.
  2. Open an order in the Shopify mobile app.
  3. Tap the admin link action.
  4. On the embedded destination page, fetch a PDF, create a blob: URL, and trigger an <a download> click.
  5. No file is downloaded and no native save/download UI appears.
  6. Open the same flow in standalone mobile Chrome; the PDF downloads successfully.

Expected

Shopify Mobile should download or open the PDF, or expose a documented native mechanism for saving the file.

Actual

The Blob download is silently ignored inside Shopify Mobile. No browser or App Bridge error is surfaced.

Related reports

Both are open and labeled bug in Shopify’s App Bridge repository.

That matches shopify-app-bridge#191, still open with no fix. Since it’s a blob: URI created purely in JS, the embedded webview has nothing to hand off to the OS downloader. Worth testing a real network URL with Content-Disposition: attachment instead of the blob, native navigation to an actual resource tends to get picked up where blob links get silently swallowed.