-
Notifications
You must be signed in to change notification settings - Fork 668
Test webview2 #14670
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
Test webview2 #14670
Conversation
| // We need to run the async ExecutePackageDownload function in a separate thread so that the Thread.Sleep does not mess up the other awaiting tasks. | ||
| //actually perform the download & install operations | ||
| pmVmMock.Object.ExecutePackageDownload(id, pkgVer, ""); | ||
| }).Wait(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Task.Run is a viable option here because there is no UI interaction from ExecutePackageDownload
This could be resolved by running pmVmMock.Object.ExecutePackageDownload(id, pkgVer, ""); on the test thread but adding a DispatcherUtil.DoEvents() after the thread.Sleep bellow (would have been needed if there was UI interaction in ExecutePackageDownload)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you also make this test async, await the download and get rid of the sleep?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not that easy to await the download. The ExecutePackageDownload would have to be refactored to return a task fo the download and install operations.
…/Dynamo into test_webview2
|
master-15 tests passed here https://master-15.jenkins.autodesk.com/view/DYN/job/DYN-DevCI_Self_Service/1319/ |
| { | ||
| AppDomain.CurrentDomain.AssemblyResolve -= assemblyHelper.ResolveAssembly; | ||
| } | ||
| System.Console.WriteLine("Finished test: " + TestContext.CurrentContext.Test.Name); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These do add more logs to the jobs output but they are useful
| /// <returns></returns> | ||
| private static object ExitFrame(object frame) | ||
| /// <param name="check">When check returns true, the even loop is stopped.</param> | ||
| [SecurityPermission(SecurityAction.Demand, Flags = SecurityPermissionFlag.UnmanagedCode)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know. I copied it from the DoEvents method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do know that the Dispatcher does call into unmanaged code when it processes its message queue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel you can probably get rid of it all, I think security permissions system is removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| } | ||
|
|
||
| [Test,Category("Failure")] | ||
| [Test] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
woohoo!
| } | ||
|
|
||
| // Wait for the DocumentationBrowserView webview2 control to finish initialization | ||
| DispatcherUtil.DoEventsLoop(() => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so essentially all devs working on tests with webview2 controls need to use this API for tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hopefully not all the time. Only if the webview2 control is expected to be visible during the test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will try to add some sort of docs somewhere
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be a really nice addition with a custom analyzer using roslyn. We could detect usage of an API that would show the WebView control in a method marked with the test attribute, and add a compiler error if we don't see this method used... anyway, for another day.
* upate * Update ViewExtension.cs * Update DocumentationBrowserView.xaml.cs * Update NotificationsViewExtension.cs * update * update * Update NotificationCenterController.cs * Test webview2 (#14670) * update * update * Update DocumentationBrowserView.xaml.cs * update * Update DocumentationBrowserView.xaml.cs * update * update --------- Co-authored-by: pinzart <tiberiu.pinzariu@autodesk.com> * Update NotificationCenterController.cs * Update DispatcherUtil.cs * Update CS_SDK.props * Revert "Update CS_SDK.props" This reverts commit cfaceb2. --------- Co-authored-by: pinzart <tiberiu.pinzariu@autodesk.com>

ex.
Some of the webview 2 controls are visible and initializeAsync is called, but they finish so fast (the thread dos not process the message in time) that Dispose is called before they get a chace to finish initialization (System.ObjectDisposedException might be thrown)
Some of the webview 2 controls are created hidden and initializeAsync will be blocked until the control becomes visible. The tests will finish and Dispose will be called. (ComExceptions or ObjectDisposedException).
Most of these crashes might happen outside of the tests that caused them. Depends on what test actually calls DoEvents (i.e tells the thread to process its message loop)
To fix these I moved most of the webview2 initialize calls on the Loaded event in this PR. Also I ensured that all tests that create visible webview2 controls are processed and finished before the test continues and eventually disposes of the control (using DispatcherUtil.DoEventsLoop)