EdgeDriver Version 116.0.1938.69 - Changed behaviour for WindowHandles Count with Open PrintDialog

[anitabogner]

We are testing a WebApp with Selenium 4 (Version 4.11) on Edge Browser.

about 3 weeks ago the Browser was updated to Microsoft Edge for Business Version 116.0.1938.54 in our company, and thus we also had to update the Webdriver to version 116.0.1938.54

We are facing the following issue now in our TestAutomation project: We use the count of WindowHandles to check if a PrintDialog was opened. So far the WindowHandles was increased by 1 when the Print Dialog was opened an we could switch to it an close it (via JavaScriptExcecutor).
Since the update we are facing the issue that the count of WindowHandles remains unchanged when the Print Dialog is opened.

The Version installed before was Version Microsoft Edge 115.0.1901.203 (no mention of For Business)

Attached file shows a screenshot of VisualStudio in Debug-Mode showing the value of WindowHandles and the state of the Browser at this time

AB#48193155

[evanbaule]

@anitabogner did you ever make progress on this issue? I saw your posts in other forums and did not have any success with adding webview to the windowtypes. Wondering if you are still having this problem or if you found a workaround. Thanks!

[anitabogner]

@evanbaule Unfortunately no progress so far :(
I also tested the behaviour with Edge / EdgeDriver Versions 117 and 118 but the issue still occurs there => WindowHandles remains 1 after Print window is opened.

Adding Webview to the windowTypes also did not solve the issue for me, because as I mentioned it does not give access to the area with the Print and Cancel buttons just the area with the document preview :(

As a workaround I tried closing the print dialog with a small AutoIt script (by sending ESC to the browser window). This basically worked but only on my local machine. In our setup the tests are running on a remote machine without user logged in. This workaround requires an active UI session to be working, so still fails in our nightly testrun.

So I'm still waiting / hoping for a reply from Microsoft if there will be a fix or information how the issue could be resolved.

[evanbaule]

@anitabogner Thanks for the response, I'm in nearly the same position. We run a variety of scripts with headless browsers where blindly throwing keypress events towards the screen would not solve any issues.

I'm experimenting a bit with kiosk-mode https://stackoverflow.com/questions/65931706/start-microsoft-edge-in-silent-printing-kiosk-printing-mode-from-command-promp as a potential alternative, something you may find to be helpful?

We try to configure the behavior so that we can either close the dialog or confirm and print based on the need at the time, so I'm unsure if this is actually going to unblock us but it appears that this startup option is going to be our best bet if we don't get a response from MS. I don't know if there is actually a way to tell the driver to open the browser in kiosk mode, but I do know that you can open the browser with a specified remote debugging port and then attach the webdriver as a secondary operation.

[bwalderman]

Thank you for reporting this. We've recently a few reports of recently changed behavior around the print dialog. I've added this to our internal backlog for investigation.