-
Notifications
You must be signed in to change notification settings - Fork 52
-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebView ZoomFactor Resets on each Navigation #3459
Comments
Double check your code your creating the window because mine was based on the sample and it defaulted the zoom to 1.0 thereby overriding my preference. |
Not sure what you're saying. If you set the value that becomes the default and that's what it reverts to every time. if you initialize with 2 it will always go back to to 2. If you don't set it it always goes back to 1. |
Actually, I think the base code that I started with (
In those handlers is |
Thanks @ajtruckle for your input. @RickStrahl does the solution provided in #2451 address your problem? |
@RickStrahl it is intentional that WebView2 zooming does not match the browser because browser zoom applies to all tabs on the same site of origin and we didn't want zooming in one WebView2 to cause other WebView2's content to also zoom. Extending your full browser example:
For WebView2, we didn't think it made sense to apply the zoom based on the web site like the browser does. This would impact all the WebView2s for that user data folder. The extreme example here is Office applications which share a user data folder so that users get cookie/local state sharing. Imagine changing the zoom of a WebView2 in Word and you see content in PowerPoint get zoomed (because they are on the same web site). The Office team did not find that behavior desirable. So instead of saving the user zoom per web site, the user applied zoom is only for the current page in the current WebView2 and is discarded on navigation. Any navigation resets the zoom factor to the default value of 1.0. Additionally, if the application itself sets the ZoomFactor property, then that is treated as changing the default value. Any user zoom is still reflected to the application through the ZoomFactorChanged event, but future navigations will reset the zoom factor to the application set default. This is documented here. |
@novac42 - no it doesn't solve the problem primarily because the @bradp0721 - I agree that the per site stickiness is not a good fit for a control, although I would say it's better than what you have now. The idea of always resetting to some default value on every new navigation feels counter intuitive especially since you are setting it at the control level. It makes it really hard to keep track of the user desired value because it constantly resets to a forced value. It always seems wrong when a value is explicitly reset for some nebulous internal reasons that aren't either explicitly set or by initiated by a user. The preferred behavior I would like to see is to have no explicit reset: I set a value when the control is loaded, and then any user changes in the control are properly captured in The current behavior is confusing because it neither matches browser behavior, nor what I would consider normal default behavior (which is set it and don't force it ever). Currently you either accept the default behavior or you have to write hacky code like what I show above to do something different - because it's the only way to track the ZoomFactor value away from the forced reset value. IOW, you make everything difficult, except the default path. What I suggest has a different default behavior, but makes it easy to implement auto-reset to some fixed value behavior (ie. like the current implementation) or any other custom behaviors. That said - I have my workaround, just feel like that shouldn't be necessary. |
I see two ways this can be fixed:
Still thing 1. is the way to go because it'll be the expected behavior IMHO. Or do nothing and see tons of questions and complaints regarding how to fix the Zoom behavior 😄 |
I keep it simple. I have 4 tabs so 4 zoom values in registry. If user changes zoom I update the view and the reg. when I activate a tab I set that zoom. For me I technically have one view control and no tabs. These are a tab control on my dialog. I find this quite simple and works for me. |
@ajtruckle - yeah that works as long as you only set the Zoom on startup. But now let your user change the zoom and then allow them to refresh the page. They'll go back to the original Zoom level (or default of 1) that you set, not the zoom they set. That's where this problem comes in. It's not one of those things that is huge issue especially depending on the application, but if you have tools that rely heavily on WebView behavior (in my case an editor and preview with 1000s of users) somebody is bound to be complaining about the non-sticky behavior and having to rejigger the zoom constantly. Heck I do myself, even if it's not often. As said - I fixed this recently with the code I show above, and that can be used to customize Zoomfactor handling, but it feels that this is way harder than it needs to be for no good reason. |
For me, if I set the zoom to 150% and then Refresh it re-creates the document and re-displays it, still at 150%. So I am probably doing custom actions in this scenario. |
@ajtruckle Yeah I'm also having trouble reproing this. If I change zoom in a webview2 control and open devtools and |
@pushkin- You are commenting on something that is over a year old from my point of view. It works for me by using the code I displayed. I won't bother fiddling with it now. |
We also run into this issue with our application and had users complain about it.
@ajtruckle We also based our code on Marius Bancila's blog post, since we are an MFC application. Yet we still see this issue. Which is to be expected as none of his code deals with it. I am curious what it is that you seem to be doing so you do not see this issue.
@RickStrahl thank you very much for the workaround. It restores the expected behavior. Unfortunately, the workaround breaks the Ctrl+0 behavior to reset the Zoom to the default, because programatically changing the ZoomFactor property, sets the new value as the new default, as @bradp0721 explained here:
To mitigate this, we extended @RickStrahl 's workaround to additionally intercept the AcceleratorKeyPressed event (we use C++/WinRT): // Restore Ctrl+0 default zoom factor behavior, as the above breaks it, because setting ZoomFactor programatically also changes the default zoom factor... (see https://github.com/MicrosoftEdge/WebView2Feedback/issues/3459#issuecomment-1538818084)
m_pWebViewImpl->m_webView2Controller.AcceleratorKeyPressed([this](const CoreWebView2Controller& webView2Controller, const CoreWebView2AcceleratorKeyPressedEventArgs& args) {
if (args.VirtualKey() == static_cast<uint32_t>(winrt::Windows::System::VirtualKey::Number0))
{
m_dZoomFactor = m_dDefaultZoomFactor;
webView2Controller.ZoomFactor(m_dDefaultZoomFactor); // 1
}
}); |
The
ZoomFactor
property is getting reset every time the WebView instance is navigated when it should maintain theZoomFactor
across navigations. We are after all looking at the same instance.Observed:
Any time you create a new WebView instance and change the source or refresh the
ZoomFactor
is reset to its initial value. If you set the value during Initialization to 2 it resets to 2. Default is 1 and it so it usually resets to 1.Additionally the
ZoomFactorChanged
event is fired whenever the page is refreshed and receives the now reset value instead of the current activeZoomFactor
the user may have changed to during using the active Web page.Steps:
Observed:
Changing zoom level works, but is not persisted across the refresh operation.
Expected:
Since you are setting the ZoomFactor on the WebBrowser instance I would expect the ZoomFactor to stay at what the user sets it to unless it's explicitly overridden at the code level.
Further the fact that
ZoomFactorChanged
is fired when the value is reset makes it very difficult to maintain this value explicitly. It would be useful to be able to distinguish between:Without this you need to use flag values to disable level capture in NavigationStarting and enable in DomContentLoaded which is a PITA for something that seems like it should be automatic since you set the value at the WebBrowser instance.
FWIW full browsers behave as follows:
Workaround
For now the workaround I use requires a bunch of extra code:
The text was updated successfully, but these errors were encountered: