uazo
commented
10 months ago I have checked how the pdf display works, but there is something I do not understand.
in windows, viewing is delegated to an internal extension 'Chromium PDF Viewer' which opens the site in OOPIF (as seen with chrome://process-internals/#web-contents ref https://www.chromium.org/developers/design-documents/oop-iframes/).
in this case, the context of the page remains the site of the pdf and therefore the content settings do not relate to the extension.
it is true that it is always possible to derive the top frame, and in that case the extension frame is derived, but I cannot manage the view. (to be evaluated: I discovered that location.ancestorOrigins exists, i.e. all iframes can know the embedders).
I don't know if it is related to the "proxy" concept, which I still don't quite understand.
to be explored
PF4Public
unfortunately, a simple change is not possible. the fact is that (quite rightly) neither the render process nor blink know that the page is a webui, and therefore the request must be forwarded to the browser. same thing for pdf pages.
the idea then is to take advantage of the content settings (render side) and ask via mojom which will control via the siteisolation check. I have no idea if it becomes performance heavy, in addition, adding calls via mojo is always discouraged by the chromium team due to possible security problems.
the alternative is to check whether it is ok to check the 'chrome' protocol on the blink side of the navigation url, but I have not seen any code that does this, so it is probably not safe.
the last idea, the longest to implement but probably the best, is to add a configuration in the settings of blink that deactivates the function and to be passed when blink is initialised, but the code indicating how to reuse the render process must also be revised (a bit like jit does).
found: IsPdfExtensionOrigin