Settings and activity
1 result found
-
5 votes
An error occurred while saving the comment An error occurred while saving the comment Raymond Davey commented
I have one further diagnostic result which may be useful.
In Chrome's DevTools for the Acrobat extension, under Extension Storage → Local, I found:
'mimeHandlerEnabled = "true"'
'mimeCohort = "master"'As a test, I changed only:
'mimeCohort = "chromeMimeHandler"'
I then repeated exactly the same POST-generated PDF report with Acrobat extension 26.8.1.5 still enabled.
The problem disappeared and the PDF displayed correctly.
So on the same machine, browser, extension version and application:
'mimeCohort = "master"' → POST PDF triggers the additional GET and fails
'mimeCohort = "chromeMimeHandler"' → POST PDF displays correctly
There is one further potentially important observation: the change to 'mimeCohort' does not persist.
If I reload the application page from which the report is generated, the Acrobat extension automatically changes 'mimeCohort' back from '"chromeMimeHandler"' to '"master"'. Once it has reverted to '"master"', the original problem returns.
So '"chromeMimeHandler"' is only a temporary diagnostic change. Something in the normal extension/page flow is actively setting the cohort back to '"master"'.
This appears to provide a reproducible A/B test of the problem without changing the application, browser or extension version.
Hopefully this gives the engineering team a useful pointer as to where the regression may be occurring.
An error occurred while saving the comment Further note. I have just tested the same machine with the Edge browser.
This extension works fine in Edge. Extension version 26.7.1.0
I do note that this is an older version of the extension. The most recent update is not available in the Edge browser store
I compared HAR captures between the working and failing versions.
Adobe extension 26.7.1.0 in Edge: the POST receives a 200 application/pdf response and no further request is made to the PDF URL. The PDF displays correctly.
Adobe extension 26.8.1.5 in Chrome: the same POST receives a 200 application/pdf response, but immediately afterwards a new GET request is made to the identical POST-only URL. That GET fails.
This suggests a possible change/regression in how 26.8.1.5 handles PDFs returned directly from POST requests.
An error occurred while saving the comment Version 26.8.1.5 does not fix the issue
I have a clean HAR file for you if you contact me directly
Can also set you up with a test case (in a live system) for you to diagnose
All other extensions are disabled. This is a clean browser session under Chrome
More info for the engineers: (In the hope of it getting escalated sooner)
I have done some further investigation which may help narrow down where this is occurring.
The HAR confirms the following sequence in Chrome with Acrobat extension 26.8.1.5:
1. The application POSTs to `/ReportLeave/ReportConfirm`.
2. The POST succeeds with `200 OK` and returns `Content-Type: application/pdf`.
3. Shortly afterwards, a new GET is made to the same `/ReportLeave/ReportConfirm` URL.
4. Because this endpoint requires POST data to generate the PDF, the GET cannot succeed and the application redirects it to its error page.
I also compared the Acrobat extension code from the working 26.7.1.0 version with 26.8.1.5.
There is a fallback path in the viewer code which can navigate `window.location.href` back to the original PDF URL after a 500 ms timeout. This would cause a new GET to the original URL and seems consistent with the document navigation seen in the HAR.
There are also changes between 26.7.1.0 and 26.8.1.5 in `common/private-api.js` around Chrome MIME handling. In particular, 26.8.1.5 adds a `mimeCohort` condition to `isChromeMimeHandlerFeatureEnabled()` and `isMimeHandlerAvailable()`. The newer version requires:
`mimeCohort === "chromeMimeHandler"`
for that MIME-handler path to be considered available. This condition is not present in the working 26.7.1.0 version.
It may be worth checking whether 26.8.1.5 is incorrectly entering the fallback/reload path for a PDF returned directly from a POST, rather than continuing to consume the original PDF response stream.
This would explain the behaviour:
reloading an ordinary PDF URL using GET works, but a dynamically generated PDF returned from a POST cannot be recreated by performing a GET against the POST URL.
Note to non-Adobe Staff reading this post: These notes refer to files embedded in the extension and cannot be fixed by us