MicrosoftEdge / MicrosoftEdge/WebView2Feedback

WebView2 creates at wrong size (possible regression?)

Open
#2,776 2 comments 0 reactions 1 assignee View on GitHub

@bradp0721 is already working on this.

Since Sep 8, 2022.

bug tracked
Dominant language
PowerShell
Stars
526
Forks
67
PR merge metrics
No merged PRs in 30d

Description

Description
It appears WebView2 always creates at the wrong size, and then quickly fires a resize event for the correct size.

Here's a Visual Studio project that demonstrates what happens:
resize-bug.zip

It's basically the Win32 getting started demo, but adapted to create a webview exactly 600x600, and then loads the following HTML string:

<h1>Hello world</h1>
<script>
console.log(`Startup window size: ${window.innerWidth} x ${window.innerHeight} @ ${performance.now()}`);

window.addEventListener("resize", () =>
{
	console.log(`Resize event: ${window.innerWidth} x ${window.innerHeight} @ ${performance.now()}`);
});
</script>

Using the debugger I verified that there is a call to put_Bounds sized exactly 600x600 prior to the call to NavigateToString to load that code. After building and running and viewing the console, it logs this:

Startup window size: 961 x 1032 @ 162.79999999981374
Resize event: 600 x 600 @ 175

Where did the size 961 x 1032 come from? It's always specified 600 x 600, but it seems it only gets the right size just after startup. It should have the correct size on startup and not fire a resize event.

This might seem fine but it's a hacky way to do things: suppose an app reads the window size immediately, then it runs some async init code, and then it attaches a window resize event. If it misses that very-soon resize event, it is left with the wrong size.

In our production app we see something even weirder but I can't reproduce it: we get a resize event for the size 961 x 1032 (i.e. the wrong size), but later on if we read the window innerWidth/innerHeight it returns the correct size. So it seems it fired a resize event with the wrong size, or it silently updated the size without firing a resize event, or since our code is pretty complicated, we just somehow fell victim to the kinda hacky way WebView2 handles resizes.

We've had the same code running for a year or two now and users only just reported this to us, so I suspect it's a regression in a recent WebView2 update.

Version
SDK: 1.0.1343.22
Runtime: stable 105.0.1343.27
Framework: Win32
OS: Observed on Windows 10 and Windows 11

AB#44174157

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.