API Review: HiddenPdfToolbarItems.md

[SamuelQZQ]

This is a review for the new HiddenPdfToolbarItems API.

[MikeHillberg]

What if I want to hide all buttons, even the ones that I don't know about because they haven't been invented yet?

[SamuelQZQ]

How about adding a CoreWebView2PdftoolbarItems.All?

[david-risney]

We have guidance to avoid adding 'All' enum entries because of versioning compat issues. If we want to support a scenario of hiding all items we could add a different boolean property like CoreWebView2Settings.IsPdfToolbarEnabled

[SamuelQZQ]

Currently, not every button can be hidden. We only allow developers to hide the buttons which we think make sense to be hidden. In the current version, we only allow hiding buttons in the red rectangle.

Developers can use WebViewSettings.HiddenPdfToolbarItems = ~0 to hide all the hidable button. But actually, it's not equal to disable the toolbar. Because there will be some toolbar buttons still available.

According to this, do you think it's still necessary to add the hide all functionality in this scenario? If we really need this, we need to make every button hidable first.

[SamuelQZQ]

I think we can add the hide-all API in the future if we need it. And keep the current API without the hide all functionality. @david-risney

[darkguy2008]

Currently, not every button can be hidden. We only allow developers to hide the buttons which we think make sense to be hidden. In the current version, we only allow hiding buttons in the red rectangle.

Developers can use WebViewSettings.HiddenPdfToolbarItems = ~0 to hide all the hidable button. But actually, it's not equal to disable the toolbar. Because there will be some toolbar buttons still available.

According to this, do you think it's still necessary to add the hide all functionality in this scenario? If we really need this, we need to make every button hidable first.

I think that instead of you guys deciding "what's best" for the developers use cases (which most/some of the time, it goes against them and sometimes it's just "what the client wants") the best option would be to give the developers the choice to actually do it. If it's already done in some buttons, why not to treat the other buttons the same way? What kind of security implications does it have if you do otherwise? You might not see the use case, but @MikeHillberg surely did, so to me that's a valid use-case too.

Just my two cents here.

[ASM-SW]

We want to use this in a Kiosk mode. Any button that can leak information or allow the user to browse the file system needs to be hidden. This includes the save as button. We also want to hide the print button because that can lead you down a path that could be dangerous.

Once you hide the save as and the print buttons there is little reason to allow the pens that allow marking and highlighting.

[FrancescoBonizzi]

I'd like a property to hide the PDF toolbar too, I'm going to implement a PDF viewer in my WPF kiosk application and I really don't want to see anything but the PDF pages and the scroll bar.

Since now it isn't possible to hide the toolbar, do you have any workaround? I saw that the toolbar div has toolbar as id, so you I thought that by executing JavaScript code to set its style to display: none it would do the trick, but document.getElementByIdin this case returns null. Then I saw that the whole PDF was sandboxes inside an embed tag, so I don't know how to make it work.

Do you suggest any workaround? Thanks!

[ASM-SW]

I have tried the HiddenPdfToolbar API. In a separate issue I posted that when I bring up the PDF search box and move my cursor between the X to close the browser and the X to close the search box the application hangs. If I wait long enough, sometimes, the hang goes away. #1889

[applefanbois]

-Let us show and hide this toolbar.
-Let us use our own UI to control these functions.