Regression: Form does not display on the foreground anymore in the beta runtime #3584

fvanheeswijk · 2023-06-21T11:48:07Z

Description
Our application can open multiple GUI threads. Some work needed to be done by Microsoft in #334 to ensure that this works correctly, but ever since it has worked fine. Now the issue is back however.

This is an urgent issue as now whenever we open new dialogs in our application they will appear behind the main window. This issue must not hit our production users so it needs to be fixed in the beta release, hopefully soon.

Version
SDK: 1.0.1823.32
Runtime: Microsoft Edge Beta 115.0.1901.14
Framework: WinForms
OS: Win11, but also reproduces on Win10

Regression
Was this working before but has regressed? Yes
If yes, what version did this last work on? Microsoft Edge WebView2 Runtime 114.0.1823.51

Repro Steps
We have produced the following example:

using System;
using System.Collections.Generic;
using System.Drawing;
using System.Linq;
using System.Runtime.InteropServices;
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Forms;

using Microsoft.Web.WebView2.WinForms;

namespace WebView2BugMultipleForms
{
    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main()
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.Run(CreateTestForm());
        }

        public static Form CreateTestForm()
        {
            var form = new Form
            {
                Size = new Size(1280, 1024)
            };

            var webView2 = new WebView2
            {
                Dock = DockStyle.Fill,
                Source = new Uri(@"about:blank")
            };
            webView2.CoreWebView2InitializationCompleted += (sender, e) =>
            {
                webView2.CoreWebView2.AddHostObjectToScript("handler", new Handler(form));
                webView2.CoreWebView2.NavigateToString(
@"<html>
    <head>
        <title>Test</title>
    </head>
    <body>
        <button onclick='window.chrome.webview.hostObjects.sync.handler.openForm();'><h1>Open new form</h1></button>
    </body>
</html>");
            };
            webView2.KeyDown += (sender, e) =>
            {
                webView2.CoreWebView2.NavigateToString(
@"<html>
    <head>
        <title>Test</title>
    </head>
    <body>
        <button onclick='window.chrome.webview.hostObjects.sync.handler.openForm();'><h1>Open new form</h1></button>
    </body>
</html>");
            };

            form.Controls.Add(webView2);

            return form;
        }
    }

    [ComVisible(true)]
    public class Handler
    {
        private readonly Form owner;

        public Handler(Form owner)
        {
            this.owner = owner;
        }

        public void openForm()
        {
            var ownerHandle = owner.Handle;
            var thread = new Thread(() =>
            {
                var newForm = Program.CreateTestForm();
                newForm.Shown += (sender, e) => newForm.BringToFront();
                var nativeWindow = new NativeWindow();
                nativeWindow.AssignHandle(IntPtr.Zero);
                newForm.ShowDialog(nativeWindow);
            });
            thread.SetApartmentState(ApartmentState.STA);
            thread.Start();
        }
    }
}

Steps to reproduce:

Install the Microsoft Edge Beta application.
Build the code.
Navigate to the directory containing the .exe file.
Open a command prompt in that directory.
Run set WEBVIEW2_RELEASE_CHANNEL_PREFERENCE=1 to prepare to use the beta runtime.
Run the .exe file of the application.
Wait until the browser has been initialized (alt-tabbing seems to help to make this go faster).
Click on the Open new form button.

The expected behavior is that the new form opens on top of the current form. This can be seen when you remove the set channel environment variable. The actual behavior is that it opens behind the current form.

AB#45354995

The text was updated successfully, but these errors were encountered:

novac42 · 2023-06-26T03:33:17Z

Thanks for reporting the issue. I've assigned this to a dev that can help follow up on this.

fvanheeswijk · 2023-06-30T14:08:07Z

Has anyone had a chance to look into this already? We hope that it's clear that this issue must be fixed before it gets into the stable release. If that's not the case then our users will not be able to work with our application anymore.

ElyssaJyu · 2023-07-03T08:36:53Z

Hi @fvanheeswijk, I've repro the issue that new dialogs will appear behind the main window in the application. I've marked this issue tracked to get a bug opened internally so we can look into how we might be able to address this. Thanks

ElyssaJyu · 2023-07-12T10:39:48Z

Hi @fvanheeswijk,

NavigateToString doesn't work in CoreWebView2InitializationCompleted
You can ensure that the web page has loaded completely after calling the Navigate method by handling the CoreWebView2 instance's NavigationCompleted event. It'd better not use keydown to call NavigateToString. (pressing "Alt" can make the window in the foreground)

webView2.CoreWebView2InitializationCompleted += async (sender, e) =>
            {
                await webView2.EnsureCoreWebView2Async(null);
                webView2.CoreWebView2.NavigationCompleted += (s, args) =>
                {
                    if (!args.IsSuccess)
                    {
                        return;
                    }

                };
         // before call NavigateToString()
        ...
}

Use newForm.Activate() or set newForm.TopMost = true as a workaround to unblock your users.
Also, could you give some details on your scenario? why do you prefer to create the form with webview2 by adding a host object to the script of webview2? Here is a code snippet in our sample project to create a new form with a webview2 control in a separate thread.

We are still working on the potential root cause. Thanks for your patience.

champnic · 2023-07-14T00:12:09Z

@fvanheeswijk We have root caused the issue and are working on a fix now. Thanks!

johna-ms · 2023-07-19T00:11:04Z

Hi the fix will be in Canary Thursday. Please verify this fixes the issue for you!

johna-ms · 2023-07-19T17:54:21Z

@fvanheeswijk I checked and it is actually in today's Canary release so you can verify with Canary any time starting now. Please let us know and thanks!

champnic · 2023-07-19T17:54:55Z

Version 117.0.1990.0

fvanheeswijk · 2023-07-20T09:38:40Z

@johna-ms @champnic I checked and it indeed works in the Canary build! Thank you! Will this fix now be made available for the current Beta build (and thus the next Stable build)?

johna-ms · 2023-07-20T18:37:59Z

@fvanheeswijk thank you for validating. Unfortunately the bug will make it into stable. The fix is expected to make it into beta Wednesday next week and into stable Monday the 31st at the latest.

fvanheeswijk · 2023-07-20T18:44:08Z

@fvanheeswijk thank you for validating. Unfortunately the bug will make it into stable. The fix is expected to make it into beta Wednesday next week and into stable Monday the 31st at the latest.

Thank you for your quick reply! It is not acceptable to us however if this bug gets into stable, this means that many of our users will not be able to work with our application anymore. This would really harm the trust we put in your product. We are also testing the beta version explicitely to catch such bugs and make sure that they don't make it into stable.

johna-ms · 2023-07-20T21:55:21Z

We are trying our best to get the fix in before stable ships (earlier than I posted above). It's still possible the fix will be delayed. I will keep you posted.

champnic · 2023-07-21T18:42:36Z

Good news - it looks like we got the fix into runtime versions 115.0.1901.183, which should be going out as the next Beta and Stable WebView2 Runtime versions :)

We really appreciate that you tested and found this issue using the Beta channel! We're looking at improvements we can make to ensure we respond more quickly to regressions found in prerelease testing to avoid the last minute fixes.

fvanheeswijk added the bug Something isn't working label Jun 21, 2023

novac42 assigned Shangminx Jun 26, 2023

novac42 assigned ElyssaJyu and unassigned Shangminx Jul 3, 2023

ElyssaJyu added the tracked We are tracking this work internally. label Jul 3, 2023

johna-ms closed this as completed Jul 24, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Regression: Form does not display on the foreground anymore in the beta runtime #3584

Regression: Form does not display on the foreground anymore in the beta runtime #3584

fvanheeswijk commented Jun 21, 2023 •

edited by champnic

novac42 commented Jun 26, 2023

fvanheeswijk commented Jun 30, 2023

ElyssaJyu commented Jul 3, 2023

ElyssaJyu commented Jul 12, 2023 •

edited

champnic commented Jul 14, 2023

johna-ms commented Jul 19, 2023

johna-ms commented Jul 19, 2023

champnic commented Jul 19, 2023

fvanheeswijk commented Jul 20, 2023

johna-ms commented Jul 20, 2023

fvanheeswijk commented Jul 20, 2023

johna-ms commented Jul 20, 2023

champnic commented Jul 21, 2023

Regression: Form does not display on the foreground anymore in the beta runtime #3584

Regression: Form does not display on the foreground anymore in the beta runtime #3584

Comments

fvanheeswijk commented Jun 21, 2023 • edited by champnic

novac42 commented Jun 26, 2023

fvanheeswijk commented Jun 30, 2023

ElyssaJyu commented Jul 3, 2023

ElyssaJyu commented Jul 12, 2023 • edited

champnic commented Jul 14, 2023

johna-ms commented Jul 19, 2023

johna-ms commented Jul 19, 2023

champnic commented Jul 19, 2023

fvanheeswijk commented Jul 20, 2023

johna-ms commented Jul 20, 2023

fvanheeswijk commented Jul 20, 2023

johna-ms commented Jul 20, 2023

champnic commented Jul 21, 2023

fvanheeswijk commented Jun 21, 2023 •

edited by champnic

ElyssaJyu commented Jul 12, 2023 •

edited