MicrosoftEdge / WebView2Feedback

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

Add silent printing abilities for WebView2 hosts. #1331

Closed adamkimsft closed 1 year ago

adamkimsft commented 3 years ago

The Web Browser control offered a way to silently print: ExecWB(IDM_EXECPRINT, OLECMDEXECOPT_PROMPTUSER...)

https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa752087(v=vs.85) https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/hh801228(v=vs.85)#idm_execprint https://docs.microsoft.com/en-us/windows/win32/api/docobj/ne-docobj-olecmdexecopt?redirectedfrom=MSDN

There doesn't appear to be a way to do that with the WebView2 component. The closest is to call IWebView2WebView::ExecuteScript passing "window.print()". This will programmatically print but it won't avoid the dialog.

This feature would be a great addition for companies that are trying to migrate from hosting the web browser control especially since there's no great workaround other than to remove this ability from their program. Since the user is already trusting a third party application to run on their system, it shouldn't be a security issue to add this feature to the WebView2 component.

AB#33544666

champnic commented 3 years ago

This is a great request, I've added it as a scenario on our backlog. Thanks!

ajtruckle commented 2 years ago

Will you be updating these issues here once they have been resolved? It would be nice to know when it will be fixed.

champnic commented 2 years ago

Yup - when we resolve the issues and they ship in a runtime or SDK update we close the GitHub issues with info about the version.

This specific scenario is a medium/lower priority on our backlog.

ajtruckle commented 2 years ago

It does surprise me that this is a low / medium. It feels that MS has its own agenda it wants to stick too rather than want the users of the tool actually need. I have waited a couple of years now for things to be done ... If my project was commercial it would have been a serious matter.

champnic commented 2 years ago

Hey @ajtruckle - Of course Microsoft has its own agenda and we get requests that are higher priority for various reasons, but we are generally quite driven by what we're hearing on this GitHub repo and how much folks care about it. We have a tool which automatically crawls these issues and generates a heuristic score based on interaction with the issue, and we use this score as input when determining relative priority.

However, since this issue was last commented on, it does appear that we've begun work on it and it's in the API review stage :) Feel free to take a look at the proposal here and leave feedback: https://github.com/MicrosoftEdge/WebView2Feedback/pull/2604/files?short_path=9b5469f#diff-9b5469f16f89f612e57b016fe9c040f7982e152235a0edd73c234c9d704a961a

ajtruckle commented 2 years ago

Hi @champnic Thanks for the link. I have had a quick look at the API and I will review more thoroughly later. Looks good.

However, it does not seem to address one of the things I needed. The current print preview in forced to the constraints of the browser control. I want ability to display the print preview dialog maximised to the users display and not the browser control in my dialog. Does that make sense? Several have said about this.

Sorry if I missed something in the API notes.


Update: I see it has the print pdf stream option to show a custom dialog. But I have no idea how to implement such a dialog with win32 in my mfc app. I was hoping for a simple solution to show a print preview maximised to the display screen. I have no interest in having to build a whole GUI print preview user experience just for this imho. Sorry!

But maybe it is easier that it sounds.

ajtruckle commented 2 years ago

Hi @champnic Any thoughts on my comments about the API? Thanks!

champnic commented 2 years ago

Thanks for the comment @ajtruckle! It does indeed seem that there is the ability to build your own custom dialog in that API. As a general policy, we don't give fine-grained control over the existing browser UI, because folks will always ask to tweak everything - colors, styling, text, layout, inclusion of controls, location, size, etc. and it makes the API surface too large and difficult to implement. Instead, the two options are generally 1) Use the default experience or 2) Build your own.

ajtruckle commented 2 years ago

@champnic True, but I am simply talking about how the ChtmlView mechanics worked. I feel that the WebView2 within a Browser app is fine - the default print preview makes sense. But it does not make sense for a webview2 control in an app.

Also, I am not talking about tweaking controls and colours and all that. I am asking for one simple flexible option:

That is all. At the moment it looks like I will just stick with CHtmlView because it works. An alternative maybe to temporarily resize the browser full screen before printing and reverting back. But I "just don't like it".

Also, I don't want the headache of having to manage a print preview output and interacting with all the array of printer settings. That is way too much work for me to do. Not to mention the 50 + languages I would have to support.

I just don't understand why you can't consider the fact that the webview2 may well be a small control on a dialog and that printing (which makes sense to do from the control) should have a "print preview maximized to the controls display monitor".

I know they are two different beasts - Chtmlview v webview2. But, stripping out lots of the functionality from chtmlview just don't make sense. How is that a positive thing? Surely its features should be the footprint and built on and made better?

My concern here is that if it won't support a inbuilt print preview maximized to view that I can't continue to use the control.

monica-ch commented 2 years ago

Hi all, we've completed our design for the https://github.com/MicrosoftEdge/WebView2Feedback/pull/2604/files! Please review the pull request and add any feedback you have about this API. We appreciate your input and support!

monica-ch commented 2 years ago

Hi all, we have shipped Print APIs as experimental in the 1.0.1414 pre-release package: https://learn.microsoft.com/en-us/microsoft-edge/webview2/release-notes?tabs=dotnetcsharp#experimental-features. Please let us know if you have any feedback!

champnic commented 1 year ago

This is now available as a stable API: https://learn.microsoft.com/en-us/microsoft-edge/webview2/release-notes?tabs=dotnetcsharp#promotions

Thanks!