[Feature] Make PDF testing idiomatic

[mxschmitt]

Customers are confused, when a PDF results in a PDF viewer and when in a download event. We should explain how to workaround it in the relevant browsers.

• [Question]: Weird case of .pdf download off Chrome's PDF Viewer #7830
• How to open PDF file with playwright? #6091
• [Question] Is it possible to set AlwaysOpenPdfExternally #3509
• [BUG] Uses internal PDF viewer to view PDFs when Content-Disposition set to inline rather than downloading #3365
• [BUG] PDF Viewer does not work in headless Chromium and leads to download the file instead #6342
• Is there an option to open pdf externally in playwright? #20633

To make it work out of the box the following changes are required:

• Chromium
  • headed: headed plugin override through CLI: https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/plugins/plugin_prefs.cc;l=67
  • upstream bug to star: https://bugs.chromium.org/p/chromium/issues/detail?id=1346939#c23
  • Headless: works
• Firefox works
• WebKit works

Workaround for Chromium for now:

  await page.route('**/empty.pdf', async route => {
    const response = await route.fetch()
    await route.fulfill({
      response,
      headers: {
        ...response.headers(),
        'Content-Disposition': 'attachment',
      }
    });
  });

[corradin]

@mxschmitt Did you also take a look at the solution I proposed in case people are not able to change the source code of the application under test? #6342 (comment)

This uses the download event for headless chrome and the page event for all other browsers that use the integrated PDF reader.

[mxschmitt]

@corradin yes I've seen that. Creative solution! Question from our side, what in your opinion gets mostly asserted / tested when working with PDF files?

waitForResponse() seems working in all the cases but it seems important to assert the suggested file name?

[rwoll]

I'd love an option on context, like disableNativePDFViewer, to get all the browser to behave the same (including headless v. headful). This has tripped us up a couple times, and right now the best option (IMO), is persistent context with PDF viewer disabled in chrome prefs file, but it would be nice if could be done with a simpler flag in PW API (or even just a command line switch for CR).

Thanks!

[corradin]

@mxschmitt. Not sure, I would like to assert that the stream a user gets back is of type pdf. File name does not matter. In my case the file name is autogenerated so I could not do an exact match either way.

[VinayKumarBM]

Can we expect a simpler solution to PDF Viewer issue any time soon?

[WahyuS002]

I think there is a typo in the highlighted text below. I think it should say "headed" instead of "headless."

[mandras73]

Do you have a python version of the workaround?

[vincenzo-gasparo]

Here's a python version of the workaround:

import re
from playwright.sync_api import Page, expect


def test_download_pdf(page: Page):
    page.goto("https://www.example.com")

    def handle_pdf(route):
        response = page.context.request.get(route.request)
        route.fulfill(
            response,
            headers={**response.headers, "Content-Disposition": "attachment"},
        )

    page.route(re.compile(r".*\.pdf"), lambda route: handle_pdf(route))

    with page.expect_download() as download_info:
        page.get_by_text("click_here_to_download_pdf").click()

[kinopop]

Here's a python version of the workaround:

import re
from playwright.sync_api import Page, expect


def test_download_pdf(page: Page):
    page.goto("https://www.example.com")

    def handle_pdf(route):
        response = page.context.request.get(route.request)
        route.fulfill(
            response,
            headers={**response.headers, "Content-Disposition": "attachment"},
        )

    page.route(re.compile(r".*\.pdf"), lambda route: handle_pdf(route))

    with page.expect_download() as download_info:
        page.get_by_text("click_here_to_download_pdf").click()

What plug-ins do I lack?

        response,

error 1 argument

        response=response,

is that true？
my error ：waiting for event " download"

[beegotsy]

The answer from @vincenzo-gasparo only works if the HTTP method is GET, also it always removes the filename, even if present.

This solution should work for any use case:

from playwright.sync_api import Route, Request # or from async_api

def override_content_disposition_handler(route: Route, request: Request) -> None:
    response = route.fetch() # performs the request
    overridden_headers = {
        **response.headers,
        "content-disposition": response.headers.get('content-disposition', 'attachment').replace('inline', 'attachment')
    }
    route.fulfill(response=response, headers=overridden_headers)

If you need to modify request method, headers or payload use route.continue_(...).

Also, there is no need to wrap the method in a lambda:

page.route("**/*.pdf", handler=override_content_disposition_handler)

[cobaltautomationdev]

@beegotsy
I have implemented a feature in my code that triggers a Chrome PDF preview popup when a specific button labeled "PO Print for Vendor" is clicked. Upon inspecting the elements within this popup, I found that there is limited interaction available; the primary options are to save the document as a PDF or print it.

async with page.expect_popup() as popup_info:
            await page.locator("#quick-process").get_by_text("PO Print for Vendor").click()
popup_page = await popup_info.value

To automate the process of saving the PDF, I attempted to invoke the print function using evaluate on the popup page object, like so:
await popup_page.evaluate('''() => {window.print();}''')

This approach successfully triggers the print dialog, which includes an option to save the document as a PDF. However, this method requires manual intervention to input a filename and confirm the save action, which prevents the automation from completing without user input.