The HtmlPage.PopupWindow() is defined as:
Perfect! …or so I thought. I fully expected that if I called PopupWindow() like this:
..that I’d get a new browser window with the default width/height on the monitor that the launching browser is on.
After all, if I called window.open() with equivalent arguments as follows that’s what would happen:
Instead, I get a small window that launches on Monitor 1. I do my main work on my Monitor 2 and I kept waiting for my popup window only to realize that it was on the other monitor. I really hate applications that do this!
Looking into Reflector, the issue seems to be that if options is passed as null in the last parameter of PopupWindow(), the call is simply forwarded to window.open(). But, if you pass an instance of HtmlPopupWindowOptions (even with no properties set) to PopupWindow(), the ToFeaturesString() that gets called to convert this strongly-typed version of the features to the string that is needed for window.open() is also changing the height/width/top/left of the popup window.
Looking over the documentation…yes, I’m male and sometimes do that *after* nothing else works. ….anyway, there it is in the remarks of HtmlPage.PopupWindow(). All the ugly details and the admission that my popup would be altered. Documented or not, it’s not acceptable to my client and I’m not putting my name on anything that launches a browser on the wrong monitor!
That’s when I decided to have another look at HtmlWindow.Navigate() which seems to more accurately mirror the behavior that I would expect out of something that purports to wrap window.open(). Going this route, we lose the strong typing of the HtmlPopupWindowOptions, but in exchange we get exactly what we are expecting when calling window.open(). The call using HtmlWindow.Navigate() looks like this:
This will fire a new window on the correct monitor and will honor the default settings for width/height/top/left.
Here’s the code.
Here’s a live sample.