Skip to main content
Participant
August 14, 2026
Answered

Bug Report – Acrobat Chrome Extension ignores web application filters when opening generated PDF

  • August 14, 2026
  • 5 replies
  • 41 views

Issue

After a recent update of the Adobe Acrobat Chrome Extension, PDFs generated from our web application no longer preserve the filters selected by the user.

The web application correctly displays the filtered list of transactions, but when the user clicks Print, the PDF opened through the Adobe Acrobat Chrome Extension contains all transactions instead of only the filtered ones.

Environment

 

  • Operating System: Windows

  • Browser: Google Chrome

  • Adobe Acrobat Chrome Extension: [26.7.2.4]

  • Chrome version: [Versione 151.0.7922.77 (Build ufficiale) (a 64 bit)]

  • Web application: enterprise banking web application

  • O.S. : Windows 11 – vers. 25H2 – build 26200.8973

Steps to reproduce

  1. Log in to the web application.

  2. Open the account transactions/movements section.

  3. Apply one or more filters.

  4. The web page correctly displays the filtered results.

  5. Click Print.

  6. The PDF is opened using the Adobe Acrobat Chrome Extension.

Expected result

The generated PDF should contain exactly the same filtered transactions displayed in the web application.

For example:

  • Web application: 21 filtered transactions

  • Printed PDF: 21 filtered transactions

Actual result

When the Adobe Acrobat Chrome Extension is enabled, the generated PDF contains all transactions, ignoring the filters previously applied in the web application.

For example:

  • Web application: 21 transactions

  • Printed PDF: 2021 transactions

The PDF therefore does not correspond to the filtered view shown immediately before printing.

Important observation

The issue occurs only when the Adobe Acrobat Chrome Extension is enabled.

If the Adobe Acrobat Chrome Extension is disabled in Chrome, the same operation works correctly:

  • the web application displays the 21 filtered transactions;

  • clicking Print generates a PDF containing the same 21 transactions.

This strongly suggests that the Acrobat Chrome Extension is interfering with the way the PDF request is handled.

Regression

This workflow worked correctly before a recent update of the Adobe Acrobat Chrome Extension.

The problem appeared after the extension was updated.

No changes were made to the web application or to the filtering functionality.

Additional evidence

When the problem occurs, the PDF is opened through the Acrobat Chrome Extension and the browser address contains the extension URL:

chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/...

When the Acrobat Extension is disabled, Chrome handles the PDF normally and the filters are preserved.

Request

Could the Adobe Acrobat Chrome Extension team please investigate whether a recent update changed the way PDFs generated dynamically by authenticated web applications are requested or opened?

In particular, could you verify whether the extension is altering, dropping or otherwise failing to preserve information associated with the original web application request, such as query parameters, session context, cookies or other request data required to generate the filtered PDF?

The issue is reproducible and the workaround is to disable the Adobe Acrobat Chrome Extension.

    Correct answer Amal Jaiswal

    ​Hi @motivated_adventuresd033 ,

    Hope you are doing well, and I'm sorry this sat without a response; that shouldn't have happened, given how complete and reproducible this report is.

    To confirm what you've already established: the Acrobat Chrome Extension appears to intercept or re-request the PDF generation in a way that loses the query parameters, session context, or other request data your web application uses to apply filters, since disabling the extension restores correct behavior immediately, and this started specifically after an extension update. That's about as clean an isolation as a bug report gets.

    This is being escalated to the Acrobat Chrome Extension team now, with everything you've documented: extension version 26.7.2.4, the before/after behavior (21 filtered transactions becoming 2021 unfiltered ones), the regression tied to the extension update rather than any change on your side, and the reproduction steps.

    One thing that would help the investigation, if you're able to share it without exposing anything sensitive: in Chrome's DevTools Network tab, could you compare the actual request being made for the PDF (URL, method, and headers) with the extension enabled versus disabled? That would show directly whether the extension is dropping query parameters, cookies, or something else specific, rather than the team having to guess at the exact mechanism.

    Thank you for the patience and for the thoroughness of the original report; this made it straightforward to act on.

    Regards
    Amal

    5 replies

    Participant
    September 11, 2026

    Follow-up – No response after 27 days

    Hello,

    I would like to follow up on this bug report, as the issue is still fully reproducible.

    The problem has now been present for 27 days without any response.

    The key point is that:

    • the web application correctly applies the filters;
    • with the Adobe Acrobat Chrome Extension enabled, the generated PDF ignores the filters (21 records become 2021);
    • disabling the Adobe Acrobat Chrome Extension immediately restores the correct behavior;
    • the problem appeared after an update of the Acrobat Chrome Extension.

    Could an Adobe Community Expert or Adobe team member please review this report and confirm whether this issue is known or can be escalated to the Acrobat Chrome Extension team?

    Thank you.

     

    Adobe Acrobat Chrome Extension 26.7.2.4
    Chrome 151.0.7922.77
    Windows 11 25H2 – build 26200.8973

    Participant
    September 11, 2026

    can this be escalated to the Acrobat Chrome Extension team?

    Amal Jaiswal
    Community Manager
    Amal JaiswalCommunity ManagerCorrect answer
    Community Manager
    September 11, 2026

    ​Hi @motivated_adventuresd033 ,

    Hope you are doing well, and I'm sorry this sat without a response; that shouldn't have happened, given how complete and reproducible this report is.

    To confirm what you've already established: the Acrobat Chrome Extension appears to intercept or re-request the PDF generation in a way that loses the query parameters, session context, or other request data your web application uses to apply filters, since disabling the extension restores correct behavior immediately, and this started specifically after an extension update. That's about as clean an isolation as a bug report gets.

    This is being escalated to the Acrobat Chrome Extension team now, with everything you've documented: extension version 26.7.2.4, the before/after behavior (21 filtered transactions becoming 2021 unfiltered ones), the regression tied to the extension update rather than any change on your side, and the reproduction steps.

    One thing that would help the investigation, if you're able to share it without exposing anything sensitive: in Chrome's DevTools Network tab, could you compare the actual request being made for the PDF (URL, method, and headers) with the extension enabled versus disabled? That would show directly whether the extension is dropping query parameters, cookies, or something else specific, rather than the team having to guess at the exact mechanism.

    Thank you for the patience and for the thoroughness of the original report; this made it straightforward to act on.

    Regards
    Amal