Page keeps loading forever after clicking on browser's 'Reload' button.
Reported by
db...@etouch.net,
Mar 6 2018
|
|||||
Issue descriptionChrome Version: 65.0.3325.146 Revision f926414266f7aecb5ec1bf1b5f93f8716976ceef-refs/branch-heads/3325@{#669}(32/64 bit) OS: Windows(7,8,8.1,10),Mac(10.12.6,10.13.1,10.13.4), Linux(14.04 LTS) URL: https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm/related?hl=en What steps will reproduce the problem? (1) Launch chrome, navigate to above url and click on ADD TO CHROME button. (2) Naviogate to PDF file(e.g. http://foersom.com/net/HowTo/data/OoPdfFormExample.pdf),then give Print command. (3) Click on 'Reload' button and observe. Actual: Page keeps loading forever after clicking on browser's 'Reload' button. Expected : Instead, the page should navigate to PDF page after clicking on 'Reload' This is a non-regression issue, seen from 'M60'(#60.0.3072.0) Note: This issue is also reproducible on M-64 Stable (build # 64.0.3282.186),M-66(build # 66.0.3355.0) and M-67 Canary (# 66.0.3355.0)
,
Mar 6 2018
,
Mar 6 2018
That's a PDF Viewer extension, not the built-in PDF Viewer.
,
Jun 1 2018
Rob, have you run across this before?
,
Jun 1 2018
This happens because the print dialog blocks the extension's main thread, and the extension has a blocking webRequest listener. Chrome waits for the extension to respond to the webRequest event, but since the extension is blocked on the print dialog, the network is stalled too. You can clearly see this by trying to navigate to example.com in a new tab - it will wait too. Ideally there should be an (extension) API to send an asynchronous or non-blocking print job. I have considered directing the print task to a child frame in a non-extension page (= in a different process) to work around this issue, but haven't gotten to that yet. Also, that would be quite a hack.
,
Jun 1 2018
Marking as available, since there's not a clear right answer here. I don't know that we're likely to introduce async print jobs in the near future, but agreed that the alternative seems rather hacky. Out of curiosity, would this be fixed with declarativeNetRequest, where the browser doesn't need to wait on the extension response?
,
Jun 2 2018
declarative_net_request is designed for blocking requests early. It cannot eliminate the need for webRequest because DNR lacks the ability to redirect based on a combination of response headers. Ideally the mimeHandlerPrivate API (combined with mime_types and mime_types_handler manifest keys) would be made a public API (or at least PDF.js being put on the whitelist of permitted extensions). Then I don't need to intercept any network request, and the extension would also work for POST requests and other response that expire after one request. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by woxxom@gmail.com
, Mar 6 2018