search

MicrosoftEdge / WebView2Feedback

Feedback and discussions about Microsoft Edge WebView2
https://aka.ms/webview2
423 stars 51 forks source link

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

Open verelpode opened 4 years ago

verelpode commented 4 years ago

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:

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 (orSystem.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:

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 commented 4 years ago

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.

Capture

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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.)

HTML-Embed-Diagram

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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):

VijayanRamachandran commented 3 years ago

@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 ?

JensMertelmeyer commented 3 years ago

With WebView2 now generally available, are there any news on this?

I noticed that there is a div "ui-container" that could easily be hidden. This can probably be done by injecting JavaScript

<body class="js-focus-visible">
    <!-- the contents of ui-container are react-based PDF UI components -->
    <div id="ui-container"><div style="background-color: rgb(247, 247, 247);"> (...) </div></div>

    <!-- This is container div for the currently open modal if exists -->
    <div id="modal-root"><div id="reading_bar_modal"></div></div>

    <div id="sizer" style="top: 41px; width: 803px; height: 4544px;"></div>

    <div id="document-container">
      <div id="embed-border" style="visibility: hidden;"></div>
      <embed id="plugin" type="application/x-google-chrome-pdf" src="file:///C:/users/localUser/Desktop/myTestFile.pdf" stream-url="chrome-extension://mhjfbmdgcfjbbpaeojofohoefgiehjai/1150c959-439e-4641-909b-f460a5384262" headers="" background-color="0xFFE6E6E6" first-page-separator="4" style="top: 41px;height: calc(100% - 41px)" javascript="allow" stream_timestamp="12352328028" full-frame="" class="">
    </div>

    (...)
</body>

However, I was not able to find any documentation on this. Will it always be an id ui-container? What about the elements inside? Are their ids subject to change?

champnic commented 3 years ago

Unfortunately this item on our backlog is relatively low priority, so I wouldn't expect a fix for a while. Can you override NavigationStarting (or perhaps WebResourceRequested? I'm not familiar with what the typical PDF navigation path is in WebView2) when going to a pdf, and instead get the pdf url for use in your own viewer using pdf.js or other?

Hiding ui-container is another option, although as noted it's not a publicly documented or supported method, and so is subject to change.

ukandrewc commented 3 years ago

I can confirm that intercepting WebResourceRequested will work, but you need to use DevTools Protocol file events to catch content delivered as blobs.

Where are you seeing ui-container? I'm seeing the pdf as an \<embed> element.

JensMertelmeyer commented 3 years ago

Where are you seeing ui-container? I'm seeing the pdf as an element.

I right-click on the PDF and selected the debug menu or whatever it's called. The <embed> element was just one of many

ukandrewc commented 3 years ago

Thanks, I was using Ctrl+Shift+I, which only shows the outer \<embed> element

SamuelQZQ commented 2 years ago

@verelpode Here is a new API proposal pull request for customizing the PDF toolbar. #1467

JensMertelmeyer commented 2 years ago

Oh, that's a good start 👍 What Edge Version will this be included? I'm not sure how to find out.

champnic commented 2 years ago

We won't know what version it will ship with until a bit further in the development process. Edge and WebView2 ship every 4 weeks, so once it's been implemented it will be released within 4 weeks.

tomgst commented 2 years ago

Hi All. Is there any update regarding : HiddenPdfToolbar in WebView21 ? I need this feature for my project :( @champnic

champnic commented 2 years ago

Hey @tomgst - it looks like the API is still in Experimental: https://docs.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2pdftoolbaritems?view=webview2-dotnet-1.0.1083-prerelease

I'm following up with the team to see what the status is here. Are you looking to completely hide the toolbar, or just a few buttons?

tomgst commented 2 years ago

@champnic I can hide all the buttons... (that will be ok for me) I use WinForm's C#. I tried to use this: https://docs.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2pdftoolbaritems?view=webview2-dotnet-1.0.1083-prerelease but unfortunately, I am doing something wrong :( Can I put my code somewhere, maybe it will be helpful for you?

Thank you for your help!

I have already asked on several groups. Each person who wrote back has provided me with the information that I will not achieve my goal because it is not possible :/

champnic commented 2 years ago

Sure, feel free to share code or a sample project that exhibits the issue. We don't currently have the ability to hide the entire PDF toolbar, but only the specific buttons listed in the enum here: https://docs.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2pdftoolbaritems?view=webview2-dotnet-1.0.1083-prerelease

When you say "doing something wrong", what is the behavior you are seeing?

tomgst commented 2 years ago

I put my code below. If you wrote about hiding ToolBar I would be grateful. I mean, using HiddenToolBar makes it difficult for me to apply it to my code(I don't know how to use it).

champnic commented 2 years ago

Below where you did AreDefaultContextMenusEnabled = false; you would add:

webView21.CoreWebView2.Settings.HiddenPdfToolbarItems = HiddenPdfToolbarItems.Print | HiddenPdfToolbarItems.Save;

And you can change which buttons you want visible or hidden.

Edit: You will also need to use a prerelease version of the SDK to get this functionality - it has not been released in the normal SDK yet.

tomgst commented 2 years ago

Thanks @champnic ! This led me to solving my problem! Below is what I did:

  1. Install new Package: obraz Microsoft.Web.View2 1.0.1133 Prerelease
  2. I added the library: using Microsoft.Web.WebView2.Core;
  3. I added the code as suggested @champnic async void InitializeAsync() { await webView21.EnsureCoreWebView2Async(null); webView21.CoreWebView2.Settings.AreDefaultContextMenusEnabled = false; webView21.CoreWebView2.Settings.HiddenPdfToolbarItems = CoreWebView2PdfToolbarItems.Print | CoreWebView2PdfToolbarItems.Save | CoreWebView2PdfToolbarItems.SaveAs; }
tomgst commented 2 years ago

@champnic The option to preview user files from the level of ,,Save As" or ,,print" in the PDF context has been disabled with hidden buttons it is OK. Unfortunately, I noticed another flaw in my code (below) Is it possible to disable in webView2 : AllowFileSelectionDialogs ?? Currently, the user can enter the social networking (Example Facebook) site and select "import file" a dialog box will appear. I want to block the ability to view the user's files on the disk. Setting this value in the registry (or GPO) does not solve my problem. I am unable to restart the EDGE process.

champnic commented 2 years ago

@tomgst Glad you got it working! The file upload control is not currently available, but being tracked in #1479 and #1544. Thanks!

fcappell commented 2 years ago

I have a report download funcitonality in my web application hosted in WebView2 within a WPF application. After the pdf file is downloaded the following popup appears image If the users clicks on "open file" link, this will be opened in the embedded pdf viewer in a new windows behind my main wpf application, giving the user the impression, nothing happened. Strangely enough the button "Show in Folder" of the same popup opens correctly over the application. As my wpf application offer a pdf viewer, a possible workaround would be to open it there, instead of using the embedded pdf viewer. Did anyone succed in doing something like that? Is that a known issue of WebView2? Can i expect a fix in a later runtime version?

champnic commented 2 years ago

Hey @fcappell - Could you open the "Opens window in background" as a new issue?

You can probably workaround this by handling the download yourself using DownloadStarting event, mark it as Handled so that it doesn't display the dialog, and instead show your own UI that when invoked, opens the PDF using your PDF viewer: https://docs.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2.downloadstarting?view=webview2-dotnet-1.0.1185.39

tomgst commented 1 year ago

@champnic The option to preview user files from the level of ,,Save As" or ,,print" in the PDF context has been disabled with hidden buttons it is OK. Unfortunately, I noticed another flaw in my code (below) Is it possible to disable in webView2 : AllowFileSelectionDialogs ?? Currently, the user can enter the social networking (Example Facebook) site and select "import file" a dialog box will appear. I want to block the ability to view the user's files on the disk. Setting this value in the registry (or GPO) does not solve my problem. I am unable to restart the EDGE process.

@champnic Hi, has anything changed? Is there any work on functionality? Unfortunately, I couldn't find a thread to solve this :/

champnic commented 1 year ago

@tomgst I believe we're tracking your request in #1544. We haven't started building that functionality yet, although I believe we have built some infrastructure that will make implementing it significantly easier. I'm checking with the team on the priority of this work. Thanks!

lamposu commented 1 year ago

When the pdf file is password protected, i need an Event to tell me password entered by the user is correct or not.

BrianRoach commented 1 year ago

I am using the HiddenPdfToolbarItems in current stable version of WebView2, but it does not appear that all the options actually succeed in hiding the buttons

CoreWebView2.Settings.HiddenPdfToolbarItems = CoreWebView2PdfToolbarItems.FullScreen | CoreWebView2PdfToolbarItems.FitPage | CoreWebView2PdfToolbarItems.Rotate | CoreWebView2PdfToolbarItems.MoreSettings;

Is an example of what I'm trying to hide, full screen being the critical button to hide, but that button stubbornly stays visible.

Is this a known issue with how the enum is mapping?

this is the webview toolbar with the following settings applied

image

BrianRoach commented 1 year ago

Additionally, I am not currently able to get the "Save As" button to show up, is there a condition of the pdf that makes that button visible? Even in None mode I am not seeing it.

vickiez commented 1 year ago

Hi @BrianRoach, this is a known issue that we are tracking in #3324 . Regarding the Save As button, a few toolbar items appear to be obsolete - I'll see if we can mark them as deprecated in our docs

itb-devs-de commented 1 year ago

Anyway we already have our own PDF viewer

Hope you don't mind me asking, @verelpode, which one do you use?

Master-Ukulele commented 12 months ago

@BrianRoach If you open a local pdf file, the "Save As" button will show up.

tomgst commented 4 months ago

@tomgst Glad you got it working! The file upload control is not currently available, but being tracked in #1479 and #1544. Thanks!

Hi @champnic Has the work on the control been completed?

champnic commented 4 months ago

@tomgst - No. It looks like work has not begun on those items, and that they are currently listed as Low Priority.