Internal and external PDF viewer, and embedded versus linked PDF's

[verelpode]

Will WebView2 include a built-in PDF viewer? In comparison, WebView 1 does not display PDF's -- it triggers the event UnviewableContentIdentified whenever PDF is encountered.

Option to hide and show individual buttons in PDF toolbar, etc.

If WebView2 will include a built-in PDF viewer, could you please provide these options that are essential for kiosk modes:

• Option to enable or disable the built-in PDF viewer. Allow an external PDF viewer to be used. WebView 1 supports external PDF viewers therefore WebView2 should also support it.
• Option to hide or show the "Save" / "Save As" buttons in the PDF viewer toolbar. The "Save As" button needs to be hidden in kiosk computers in order to prevent access to the local file system or documents folder.
• Option to override what happens when the "Save As" button is clicked. In this case, the "Save As" button is visible but the app has the option to make the "Save As" button do something other than the default built-in behavior.
• Option to hide or show the "Print" button in the PDF toolbar.
• Option to hide or show the "Full screen" button in the PDF toolbar.
• Option to hide or show the "Add Notes" button that Microsoft Edge currently shows in its PDF toolbar, because this button is unsuitable in shared computer and kiosk mode environments. For example, one user of a kiosk computer should not be able to read the notes created by a previous user.

PDF's via "embed" element versus simple link to PDF

When supporting external PDF viewers, please provide info about whether the PDF is simply a URI to a PDF file versus a HTML <embed> element. In WebView 1, the UnviewableContentIdentified event doesn't say whether it was triggered via an <embed> element or not. Could you please provide this info in WebView2? Here is an example of a HTML snippet that displays a PDF in an <embed> element:

<embed width="100%" height="100%" src="https://www.example.com/xxxxxxxx/TestPdfFile.pdf" type="application/pdf" style="margin:0px;padding:0px;overflow:hidden;display:block;">

Are you able to make WebView2 support an external PDF viewer that also supports the <embed> element meaning an external PDF viewer that is displayed inline/WITHIN a HTML webpage? In WebView 1, this issue is handled in a non-ideal manner. WebView 1 triggers its UnviewableContentIdentified event regardless of whether the PDF content was encountered via <embed> or a simple URI/link to a PDF file, and this works just fine for a simple link to a PDF file, but is somewhat problematic in the case of <embed> because it doesn't report whether the origin is <embed> or not, and it doesn't support an external PDF viewer displayed inline within a page. How can you improve this situation in WebView2? This issue depends on whether or not WebView2 will include a built-in PDF viewer.

Inability to download PDF files because of cookie access failure

Especially when WebView2 is run in a separate-process mode, it is very important to support cookie retrieval, otherwise it becomes impossible for an external PDF viewer to download + display PDFs in all cases.

We are required to download + display PDF files from websites that only authorize the PDF downloads if the correct temporary/session cookie is available, but when WebView 1 runs in a separate process, the temporary cookies in the separate web process are unavailable to the app using WebView. When our app does a HTTP download of a PDF, it uses Windows.Web.Http.HttpClient but HttpClient doesn't see the temporary cookies in the WebView process, thus the website refuses to provide the PDF file.

Our app subscribes to WebView.UnviewableContentIdentified and then uses Windows.Web.Http.HttpClient (or System.Net.Http.HttpClient) to download the PDF file, but the website denies it because of the missing cookie. We need a way of giving HttpClient access to the same cookies as WebView despite the fact they're running in different processes. Thus if WebView allowed us to retrieve the cookies, then we could copy them for use with HttpClient.

Thus for WebView 2, it's important to support cookie retrieval or transfer/sharing between processes.

Even if WebView 2 includes a built-in PDF viewer, cookie retrieval still needs to be supported in order to allow the app to download other file types (other than PDF) when the user clicks a file download link in a webpage.

See also HttpBaseProtocolFilter.CookieManager. Can you make WebView2 more compatible with CookieManager? WebView 1 fails to be compatible with CookieManager when the WebViewExecutionMode.SeparateProcess option is used. Cookies stored to disk can be retrieved, but cookies fail to be retrieved when they are only stored in RAM when:

• Windows.Web.Http.HttpCookie.HttpOnly == true; or
• Windows.Web.Http.HttpCookie.Expires == null

Double request for PDF doesn't necessarily work with all websites

Can WebView2 eliminate the double request for the same URL that occurs when the event UnviewableContentIdentified is triggered in WebView 1?

In WebView 1, the procedure is:

1. WebView requests URL http://ABC.
2. WebView receives HTTP Response message and notices that the content type is PDF.
3. WebView notices that it doesn't support PDF, so it triggers event UnviewableContentIdentified and sets WebViewUnviewableContentIdentifiedEventArgs.Uri to http://ABC.
4. An external PDF viewer receives the event UnviewableContentIdentified and proceeds to use Windows.Web.Http.HttpClient to send a request for the URI specified in WebViewUnviewableContentIdentifiedEventArgs.Uri meaning http://ABC in this example.
5. Hopefully the website provides exactly the same response when http://ABC is requested for the second time, but this is questionable when the URL is a dynamic web-app and not a simple static file.

To be fully reliable with dynamic web-apps, I think ideally WebView2 would support the external PDF viewer without causing the same URL to be requested/downloaded twice. I think this means WebView2 would have to download the PDF and then transfer the downloaded PDF data to the external PDF viewer, instead of just passing the URL to the external PDF viewer. However, that's extra complexity and I'm unsure how important this is. Admittedly, so far, the particular websites we use function correctly when the same URL (with dynamic content) is requested/downloaded twice. Thus our top priority is actually the cookie problem, not the double request.

AB#28495879

[liminzhu]

Will WebView2 include a built-in PDF viewer?

Yes, you get the same experience from viewing pdf in the Chromium-based Microsoft Edge browser :). This is WebView2 navigating to https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf.

Option to hide and show individual buttons in PDF toolbar, etc.

I think for your scenario, you might be able to use some pdf libraries like pdf.js to customize your viewer.

[verelpode]

@liminzhu

I think for your scenario, you might be able to use some pdf libraries like pdf.js to customize your viewer.

We are unable to modify the websites to make them use pdf.js because the websites are produced by other companies. Even if we somehow managed to convince one of the companies to use pdf.js, the chances of convincing all of them are zero. Anyway we already have our own PDF viewer, which was necessary because WebView 1 doesn't support PDF. This give us complete control over which buttons are displayed to users.

The problem is, I cannot see any way of configuring WebView2 to use our own PDF viewer. This is supported in WebView 1 via the event UnviewableContentIdentified but I don't see an equivalent in WebView2. Thus I suggest a solution as follows:

1. Add a IsPdfEnabled or IsPdfViewerEnabled property to IWebView2Settings.
2. When IsPdfEnabled == false and PDF content is received, set suitable properties in IWebView2NavigationCompletedEventArgs: Set the IsSuccess property to false, and set a IsUnsupportedContentType property to true (or otherwise indicate via the WebErrorStatus property). This proposed property is described in issue #43.
3. Always set a MediaType property in IWebView2NavigationCompletedEventArgs to "application/pdf" (from the HTTP Response headers) regardless of whether IsSuccess and IsUnsupportedContentType are true or false.
4. Apps will subscribe to the NavigationCompletedEvent and check for the condition MediaType == "application/pdf" and IsUnsupportedContentType == true and display their own PDF viewer.
5. This same technique also works for other unsupported content types, not only PDF's.

It causes big headaches when people try to migrate to a new version (WebView2) but it provides less functionality than the old version. Therefore I think WebView2 should support external PDF viewers because WebView 1 does. Not only is it a compatibility issue, it's also just plain useful to support external viewers for any unsupported content type (not only PDF).

Although we already have our own PDF viewer, it would still be excellent to have the ability in WebView2 to hide or disable the aforementioned sensitive buttons in the built-in PDF toolbar. Although we like our own PDF viewer, there exists a significant limitation of external PDF viewers: They're only partially compatible with websites that use the aforementioned <embed> element to display a PDF embedded within a HTML page (instead of linking directly to a PDF file).

[liminzhu]

We are unable to modify the websites to make them use pdf.js because the websites are produced by other companies.

Oh makes senses, it'd only easily work if you're displaying your own pdfs. I think it could make sense for us to expose an UnviewableContentIdentified event to deal with not pdf (because pdf support is built in, if you want to use external pdf viewer that'd naturally go through some means), but word docs and an array of stuff that isn't view-able in the browser.

Another potential way I can think of is to use WebResourceRequested event to detect any .pdf file, and then the hosting app can do whatever it want with it. This would be similar to the workflow you suggest.

With regard to customizing the browser pdf viewer, tbh I'm usually extra cautious when taking on dependencies such as the browser pdf viewer. I don't think such things have any sort of backwards-compatibility promises, but our API will when we hit stable release. So let's say the browser decides to add/delete some buttons in the pdf viewer and this may end up breaking our API and any developers that depend on it.

[verelpode]

@liminzhu

Another potential way I can think of is to use WebResourceRequested event to detect any .pdf file, and then the hosting app can do whatever it want with it.

Correct me if I'm mistaken, but my understanding is that the WebResourceRequested event cannot be used in that manner because this event only provides access to the HTTP Request message, not the Response message. In order to detect PDF or any other content-type, the Response message must be inspected, not the Request.

The content-type is located in IWebView2HttpResponseHeaders. The particular header to find is the equivalent of:
Windows.Web.Http.HttpResponseMessage.Content.Headers.ContentType.MediaType

Originally I thought the same as you, and I've noticed a couple of other people who were also tripped up by WebResourceRequested, so apparently it is easy to accidentally miss the fact that, although IWebView2WebResourceRequestedEventArgs does contain a Response property, it is always set to null by WebView2 and also WebView 1. An app can set the Response property in order to override the Response, but if the app gets the Response property, then it gets nothing other than what it already had.

Or if I'm wrong about this, please tell me!

it could make sense for us to expose an UnviewableContentIdentified event to deal with ... word docs and an array of stuff that isn't view-able in the browser.

Yes please! We have external document viewers already. If we switched from WebView 1 to WebView2 today, and if WebView2 has no equivalent of UnviewableContentIdentified, then we'd start receiving messages from people saying:
"Why can't I view this Word/Excel/PowerPoint document anymore? It worked previously but not anymore!"

... browser decides to add/delete some buttons in the pdf viewer and this may end up breaking our API and any developers that depend on it.

Do you mean your preference is to allow external PDF viewers rather than customization/settings for the built-in PDF viewer? If that's your preference, then you and I have the same preference. But there is a catch and I don't know how WebView2 can solve this: External PDF viewers work great in the case of a HTML webpage that contains a clickable link to a URI that responds with a PDF, but there exists another case that runs into problems: When the HTML <embed> tag is used to display a PDF within a HTML webpage, instead of displaying the PDF in a separate window/tab/popup. How can WebView2 deal with this issue?

Here's what happens when you try it in WebView 1:

1. WebView 1 encounters the HTML <embed type="application/pdf" src="..."/> and notices that the content-type is PDF and notices that it doesn't support PDF, and so it triggers the UnviewableContentIdentified.
2. The PDF opens in a separate new window/tab/popup that contains the external PDF viewer, as if the WebView.NewWindowRequested event was triggered, despite the fact that no new window was requested.
3. In the space where the <embed .../> tag exists in the HTML webpage, there now appears a big blank empty white space, a large hole in the webpage, because WebView 1 doesn't support PDF. Whereas in WebView2, this space isn't empty, rather it displays the built-in PDF viewer in the space.

This raises the question of whether WebView2 should provide the ability for external document viewers to fill the aforementioned big blank empty white space in the HTML webpage where the <embed .../> tag exists. If you say, "Yes let's do that", then my question is "How?", considering that WebView2 runs in a separate process that displays a special HWND that floats over (covers) the portion of the app window where the WebView2 control/instance was created.

[verelpode]

@liminzhu

As I'm thinking through this, how do you plug in and position your own viewer for embedded resource (<embed ...>/<iframe ...>) that covers part of the webview?

We can't? In order to achieve this, I think it would require new methods and events in WebView2:

1. WebView2 would need a method that allows the app to retrieve the current bounds rectangle of the specified <embed ...> or <iframe ...>.
2. The aforementioned method would additionally need to return a rectangle that intersects the bounds rectangle and represents the portion that is visible meaning not cut off as a result of scrollbars or otherwise.
3. Via an event, WebView2 would need to notify the app whenever the aforementioned rectangles change.
4. Also requires compatibility with the horizontal and/or vertical scrollbar inside WebView2. Presumably WebView2 would trigger the same event (the aforementioned event) whenever the horizontal and/or vertical scrollbar is used. Or maybe some other technique for handling scrolling.
5. Also missing a solution to deal with the fact that our own viewer (or any GUI an app displays) is unable to cover part of WebView2 because the webpage is displayed in a separate HWND that covers the app window. Any viewer or GUI that the app displays remains underneath the web HWND even if the Z-order of the WebView2 control is configured such that the doc viewer should cover part of the WebView. i.e. the Z-order is ignored. Whatever the app does, the webpage still covers the app, and no viewer in the app can cover the WebView. AFAIK. This aspect might behave differently in WPF versus UWP versus "XAML Islands" versus WebView 1 versus WebView2.

Unfortunately it sounds like it's probably an advanced and complicated feature.

Damn, I wanted to upload a diagram but GitHub is broken today. (DevTools Console shows JavaScript errors.)

[verelpode]

@liminzhu -- GitHub is working again, so here's the diagram I wanted to post. (Actually I don't think you need it, but I'll post it anyway because it helped me clarify my own thoughts, and it can benefit other random readers of this issue.)

If the app wants to display its own doc viewer that covers the <embed ...> part of the webpage, then I think this doc viewer can only cover the webpage if it exists in a HWND. Thus 3 HWND's would exist in total, as follows, listed in Z-order from back to front:

1. HWND of the app window.
2. HWND of the WebView2, displaying content produced by separate web process. Covers the part of the app window where the WebView2 Control exists in the app.
3. HWND displaying a doc viewer. This HWND would cover the <embed ...> part of the webpage/WebView2. Ideally this HWND would run in the same process as the app window.

Is that possible to support in WebView2 or is it too complicated? (Such a solution would also have to deal with the fact that UWP apps cannot directly create Win32 HWND's, but maybe that's no problem anymore because recently the AppWindow API was added to UWP.)

Note it's possible that my descriptions of WebView2's HWND are inaccurate because I don't have full knowledge of how the UWP/XAML WebView2 Control will be implemented. I also don't have full knowledge of how HWND's may be used internally in Microsoft.Toolkit.Wpf.UI.Controls.WebView or "XAML Islands". I welcome corrections to my comments.

[verelpode]

@liminzhu -- I thought of a possible solution that would permit external PDF viewers while also supporting <embed ...> and <iframe ...> without the difficulty of multiple overlapping HWND's. WebView2 could potentially have a feature that allows apps to configure WebView2 to replace WebView2's built-in PDF viewer with a specified Blazor WebAssembly. For this to work, WebView2 would need to give this Blazor WebAssembly access to the built-in PDF viewer as a minimal barebones element that has no toolbar (because otherwise it would be too difficult for the WebAssembly to render PDF entirely by itself). Thus the Blazor WebAssembly would create whatever toolbar/buttons/GUI it desires (as HTML/DOM elements), and then it would instruct WebView2 to create/display the minimal PDF viewer element below this toolbar. This would permit complete customization of the PDF toolbar.

This feature should also work for other document types, not only PDF. If the document type is something other than PDF, then the Blazor WebAssembly must completely render the document entirely by itself, whereas if the document is a PDF, then the Blazor WebAssembly could use the minimal PDF element inside WebView2 and supplement it with a customized toolbar.

The WebAssembly runs in the WebView2 process and can be tightly integrated with the HTML webpage thus it would support the case where a PDF or other document is displayed inside <embed ...> and <iframe ...>. In contrast, when code runs in the app process separate to the WebView2 process, then it's difficult to integrate it with <embed ...> and <iframe ...>.

It may also be worthwhile to reconsider the simple idea of making settings in WebView2 that enable/disable each button or function in the built-in PDF viewer in WebView2. I remember you disliked this solution for understandable reasons, but it's much simpler than the WebAssembly idea. On the other hand, the WebAssembly idea is far more powerful and customizable.

Thus at least 3 possible solutions exist:

1. Allow apps to implement their own PDF viewer that runs in the app's process (not in the WebView2 process). This is supported in EdgeHTML-WebView and works well for PDFs (and other documents) that are displayed in a separate tab or window, but it doesn't truly support <embed ...> and <iframe ...>.
2. Make settings in WebView2 that enable/disable each button or function in the built-in PDF viewer in WebView2. Simple but provides only a low degree of customization.
3. Allows apps to configure WebView2 to replace WebView2's built-in PDF viewer with a specified Blazor WebAssembly. This WebAssembly would need to be able to use/control a minimal barebones version of the built-in PDF viewer that has no toolbar. The WebAssembly would create its own customized toolbar (as HTML/DOM elements) that controls the barebones built-in PDF viewer in WebView2.

In any event, at the very least, I would really appreciate it if WebView2 supports at least the same amount of functionality as EdgeHTML-WebView currently supports, meaning the app can display its own document viewers but these document viewers aren't integrated into the HTML webpage meaning it doesn't truly support <embed ...> and <iframe ...> but is still very useful.

[verelpode]

To ensure that the Blazor WebAssembly PDF viewer feature really does work correctly, you could make WebView2 always use a WebAssembly to display PDF's, in all cases. When apps configure WebView2, the default setting would be to use the built-in WebAssembly that displays PDFs, and apps would have the option to override/replace this WebAssembly.

You could provide the source code of the WebAssembly of the built-in PDF viewer, or a sample similar to the built-in PDF viewer. This would allow app developers to quickly understand how to modify this WebAssembly to implement their own customizations.

This would mean that the built-in PDF element in WebView2 would always be a minimal barebones element that never has its own toolbar. The PDF toolbar would always be created as HTML/DOM elements by a WebAssembly that controls the PDF viewer, and this WebAssembly would be either the default built-in one or one supplied by the app developer who configures/uses WebView2.

Alternatively, you could say that this WebAssembly is required to entirely render the PDF all by itself, but this requirement would make this feature difficult to use, therefore I suggest that a small WebAssembly controls a barebones PDF element in WebView2, thus the actual PDF rendering would be performed in WebView2/Chromium outside of the WebAssembly. Thus, ideally, the PDF viewer WebAssembly would just simply make the PDF toolbar and link up this toolbar with a barebones PDF element in WebView2 that has no toolbar of its own.

Thus apps could fully control and customize the PDF viewer, as well as providing viewers for other kinds of documents.

[verelpode]

Replace built-in PDF viewer with specified HTML + JavaScript

An alternative solution: Instead of providing a WebAssembly that replaces the built-in PDF viewer, the app provides HTML + JavaScript that replaces the built-in PDF viewer. This HTML document would define buttons for the PDF toolbar, and it would use JavaScript to make these buttons react when clicked. The JavaScript would control a minimal barebones PDF element that has no toolbar of its own. The actual PDF rendering is performed by WebView2/Chromium.

Also provide an example HTML + JS file that app developers can use as a starting point for customizing the PDF viewer.

This is a fairly decent solution in the case of PDF documents, but the disadvantage is that it doesn't really support document formats other than PDF because it's too difficult to write document renderers in JavaScript. Thus the Blazor WebAssembly idea is a more powerful idea.

[verelpode]

I just found out that we're going to be adding support for a special button/feature in the toolbar of our own PDF viewer, thus I really hope that WebView2 will support external document/content viewers equally as well as (or better than) EdgeHTML-WebView does currently.

In EdgeHTML-WebView, external content viewers are currently supported via the event UnviewableContentIdentified. Although this event is imperfect in some cases (HTML <embed> and <iframe> cases), nevertheless it's still very useful and I would hate to lose this functionality.

Re the naming of the UnviewableContentIdentified event: In the case of WebView2, PDF isn't "unviewable content" by default, but WebView2 could treat PDF the same as unviewable content when WebView2's built-in PDF viewer is disabled via a setting in IWebView2Settings.

It would also be great to have more info in the event args of UnviewableContentIdentified: A property that specifies where the unviewable content should have been displayed, meaning one of these:

1. Normal (such as a URL that directly points to a PDF, without any HTML webpage).
2. Inside a HTML <iframe> (inline frame) element inside a HTML webpage.
3. Inside a HTML <embed> element inside a HTML webpage.

If possible, it would also be good to include (in the event args):

• When applicable, an ID/identifier of the HTML <embed> element (the webpage may contain multiple <embed> elements, thus an identifier indicates which one).
• When applicable, an ID/identifier of the HTML <iframe> element.

[VijayanRamachandran]

@liminzhu , @verelpode ,

We also have this requirement that we need to load a pdf in WebView2 and by default in PDF viewer individual buttons should be in disabled state ( So that it cannot be used when our application is in Kiosk mode )

Can you please help us by providing suggestion that should we use custom PDF viewer ( like pdf.js ) as mentioned early in the conversation or there are some plans that WebView2 will support disabling of individual buttons in default pdf viewer ?