New issue
Advanced search Search tips

Issue 819147 link

Starred by 3 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Page keeps loading forever after clicking on browser's 'Reload' button.

Reported by db...@etouch.net, Mar 6 2018

Issue description

Chrome 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)
 
Actual_PDF.mp4
917 KB View Download

Comment 1 by woxxom@gmail.com, Mar 6 2018

Bisect info: 388903 (good) - 388918 (bad)
https://chromium.googlesource.com/chromium/src/+log/bf5af045..cc6f5bb2?pretty=fuller

There is no definite suspect AFAICT without running a per-revision bisect so here's a few that deal with loading:
r388910 "Enable setting deferral state on ResourceDispatcher at request start"
r388914 "Set service worker response info data for foreign fetch intercepted fetches."
r388916 "Remove a hack in DocumentLoader where ApplicationCacheHost gets recreated"

Landed in 52.0.2715.0
Status: Untriaged (was: Unconfirmed)
Components: -Internals>Plugins>PDF -UI>Browser>PrintPreview Platform>Extensions
That's a PDF Viewer extension, not the built-in PDF Viewer.
Cc: rob@robwu.nl rdevlin....@chromium.org
Rob, have you run across this before?

Comment 5 by rob@robwu.nl, 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.
Status: Available (was: Untriaged)
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?

Comment 7 by rob@robwu.nl, 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