Use a virtual URL instead of a PluginDocument for loading the PDF extension |
||||||
Issue descriptionCurrently we load the PDF extension inside a PluginDocument, which triggers loading a mime handler process. This extra process introduces memory and performance overhead. In addition to fixing up the virtual URL, we would also have to do a bit of work to pass the original request through to the extension and make saving work. I don't think it would be too hard though. You can see that most things just work by visiting the extension directly: chrome-extension://mhjfbmdgcfjbbpaeojofohoefgiehjai/index.html?http://www.cbu.edu.zm/downloads/pdf-sample.pdf
,
Apr 4 2016
Have you already thought about how you're going to synchronize the virtual URL and the committed URL? This is the flow of opening a PDF URL with an extension: 1. Redirect .pdf URL to chrome-extension:// 2. Replace the chrome-extension:// URL in the omnibox with the original URL 3. Process virtual URL changes (by the user) and/or committed URL changes (by the extension). Last year I proposed an API for step 2, but there are still some open questions concerning step 3: https://groups.google.com/a/chromium.org/forum/#!msg/apps-dev/95IVTx4AiFU/gax8vKlbTD4J
,
Apr 5 2016
Thanks Rob - I haven't thought about the details and don't really have the time to take this up but some others were interested. I remember you having a proposal - it may well be that we just need to find consensus on what you have :)
,
Jun 4 2016
,
Jun 5 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 5 2017
Assigning this to ekaramad@ who is already working on the PDF re-design work ... feel free to merge it into any existing tracking bug you may have.
,
Jun 6 2017
We are trying to load the PDF extension directly inside the ContentFrame of <ebmed> which means we can keep PluginDocument (we need to support <embed>-ed PDF anyway). Right now we are working on the best design to properly support postMessaging. Marking this as duplicate of the tracking bug for reworking/removing MimeHandlerViewGuest. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by dsinclair@chromium.org
, Apr 4 2016