Browser Automation File Downloader Framework

What problem it solves

Many institutional or government sites do not expose a direct file download link. The target content may depend on login state, cookies, sessions, or a print-to-PDF action; some tasks also require paging, search, filtering, and batch processing. In those cases, requests is often not enough.

How the skill works

The skill abstracts site-specific file download logic into a reusable browser-automation workflow. It first decides whether session persistence or a direct download link is required, then selects the most stable file path. The core strategies are ranked: direct download links, a Print page with page.pdf(), and a detail-page page.pdf() fallback. Implementation starts by diagnosing the DOM, then adapting URL patterns, waiting behavior, and window-opening behavior to the site type. For ASP.NET WebForms sites, the skill avoids page.goto() for detail pages to reduce the risk of losing __VIEWSTATE; opening the target URL with window.open(url, '_blank') in the same context is more stable. Waiting strategy prefers domcontentloaded and expect_download over networkidle, which can hang on ads or analytics. After download, the PDF should be validated so page guides or disclaimers are not mistaken for the target file.

Boundaries and cautions

If the file has a direct .pdf or .xlsx URL and no login is needed, requests is sufficient. For complex front-end rendering, pagination, or cross-entity lists, matching list-page text alone can produce false positives, so detail pages should be opened and verified. Print pages are usually cleaner than detail pages, but validation should ignore functional buttons such as Print or 列印 when checking for layout occlusion.