Browser window relative screen position

This morning, I noticed an issue with a particular popup browser window that my development team's browser-based application opens. With the application running in an Internet Explorer instance in the right monitor on my dual-monitor dev system, when the popup window was opened, it appeared in the center of the left monitor.

I decided to change this behavior to have the new popup window appear on top of the parent window, to make the appearance of the new window more obvious. I knew that the location of the new window could be specified relative to the screen in parameter 3 of the Javascript window.open(URL, windowName, windowFeatures) call in IE using the top and left attributes, like:

window.open('http://localhost/', 'newWindow', 'top=200,left=300')

What I wanted to do was supply top and left attribute values based on an offset of the screen position of the parent browser window. However, it wasn't clear to me how to get the parent window position.

Google searches such as javascript window screen position weren't much help -- no obvious solutions to my question among the first several pages returned. Searching on "location" instead of "position" was even less help, since the results included a lot of keyword collisions with the location (URL) property of the window object.

Eventually I did come up with a quirksmode.org page with the answer I was looking for by searching on "screenX", the attribute used with window.open on Navigator/Mozilla/Firefox to specify the horizontal position of a new window. The solution: In IE, the screenLeft and screenTop properties give you the horizontal and vertical positions of the browser window relative to the screen, respectively. (screenX and screenY are apparentely the equivalent properties in Mozilla, although I haven't tested this myself.)

On a page with frames, self.screenLeft will return the horizontal position of the current frame relative to the screen, whereas self.screenleft will give you the position of the browser window relative to the screen.

Interestingly, support for the screenLeft and screenTop properties apparently was first introduced in Internet Explorer 5. (This is why my copy of The Flamingo was no help in finding the solution -- my old copy is only current through IE 4.) This seems to indicate that in IE 4, you could set the position of a window (either initially in the window.open() call, or later via the window.moveTo() method), but there was no way to get the position of the window!

In any case, I was able to solve my original problem of the IE popup window appearing in the wrong place by getting the screen coordinates of the parent window using calls to top.screenLeft and top.screenTop, then adding a delta to each of those values and using the adjusted values in the call to window.open().

Firefox Find Next/Prev shortcut keys

Firefox provides pretty nice hotkey support for the "Find Next" / "Find Previous" functionality of its incremental find/search feature. For the "Find Next" feature, several hotkeys are supported:

• Alt + n - Displayed on the Firefox Find Bar
• F3 - Standard in many Windows applications (Visual Studio, Word, notepad.exe, but not IE)
• Ctrl + g (Find again) - Displayed in the Firefox Edit menu; used by a few other apps

For "Find Previous", Alt + p, Shift + F3, and Ctrl + Shift + g are supported, which nicely mirror the "Find Next" shortcuts.

I like this broad hotkey support for these functions; I think the (arguable) inelegance of the redundant hotkeys is outweighted by the usability benefit of having whichever common Find Next hotkey combination that is intuitive to a particular user be supported.

The incremental find feature itself and its benefits have already been covered pretty well by Jeff Atwood -- head over there to read up if you aren't familiar with the feature.

IE prompts for credentials when accessing an Integrated Authentication site in the Trusted Sites zone

I encountered a problem earlier today where when accessing a website set up to use Windows Integrated Authentication on my development machine across the LAN from my copy of Internet Explorer 7 (beta 3) on my test machine, Internet Explorer 7 was unexpectedly prompting me for credentials. I expected my credentials to be provided automatically via Integrated Authentication.

At first I thought that this might be an IE7-specific issue, but Googling for variations on "IE7 Integrated Authentication prompt" didn't turn up anything.

I then supposed that the issue might be a general Internet Explorer configuration issue, not specific to IE7. A Google search on "ie 'integrated authentication' prompt" turned up as its first hit a useful Microsoft Knowledge Base article, Internet Explorer May Prompt You for a Password.

Among other useful information, the article mentions that IE will prompt for credentials if it thinks the site being connected to is an Internet site (a site not located on the local LAN). This prompted me to check on my client machine IE's Tools menu | Internet Options | Security tab. In the Security tab, my web server machine was set as a member of the Trusted Sites zone.

I removed the web server machine from Trusted Sites and restarted IE. Somewhat ironically, Integrated Authentication then started working as expected; I could access the website on the server machine without being prompted for credentials. Apparently, at least in this case, IE interpreted the machine being present in the Trusted Sites zone as meaning that the machine was located out on the Internet (not internally on the LAN).

On another test machine running Windows 2003 Server that I used as a client to test the Integrated Authentication on my internal web site, I needed to not only remove my server machine from the Trusted Sites zone, but to explicitly add the machine to the Local Intranet zone before Integrated Authentication worked properly.

For both client machines, I had also verified that in the Internet Options dialog, in the Advanced tab, the "Enable Windows Integrated Authentication" checkbox was checked. (Apparently this checkbox is not checked by default on some Windows 2000 Server machines, which can cause Integrated Authentication to not work properly.)

Bounds Test v2.0.1 Released

I've posted an update, v2.0.1, to Bounds Test, my on-screen ruler utility. Updated in this release:

• The window Width and Height properties are now displayed in bold, and at the top of the properties list.
• Removed the display of window X and Y properties (as they were redundant with the Left and Top properties, which are also displayed).
• Windows XP themes/styles are now used by the application if they are supported by and enabled in the host operating system.
• Added a right-click context menu with an "About" dialog.

Get it from my utilities page, or just download it directly: BoundsTest 2.0.1 (9k)

Using XP Styles in Windows Forms 2.0 controls hosted in IE

As part of my investigation for an upcoming project at work, I've done some work to determine whether and how Windows Forms controls hosted in Internet Explorer can be made to use Windows XP Styles without having to use a .manifest file on the client machine. (We make an effort to minimize or eliminate client-based requirements for our application, so that clients can simply point their copy of IE to the app and have everything "just work.")

I found that including a call to Application.EnableVisualStyles() causes the control to be rendered using Visual Styles. For example, a simple Windows Forms 2.0 test control that I put together is normally rendered by IE 6 as show in the image on the left; with the call to Application.EnableVisualStyles() placed in the control's constructor method, the control renders like the image on the right:

XP Styles Disabled

XP Styles Enabled

This behavior may be different from previous .NET framework versions; my boss (the team's former technical lead -- a guy who knows his stuff) reported to me that he spent a fair amount of time back when we first migrated to using Windows Forms controls hosted in IE trying to get XP Styles enabled, when we were using the 1.1 .NET framework, without success.

The behavior is also directly contrary to the Microsoft documentation of the EnableVisualStyles method, which states:

This method will have no effect for controls hosted in Internet Explorer.

This makes me nervous about depending on this behavior, since Microsoft might decide to change it as a "bug fix" to make the behavior be in line with the documentation. (However, why making a change to create a difference in behavior between Windows Forms controls hosted in IE and WinForms controls hosted elsewhere would be a desirable change, I'm not sure, so perhaps no change is likely to be made.)

I also found that if the EnableVisualStyles() method is called for any particular control in a given IE window, it affects all controls on the page. (This does make sense, given that the method being called is a member of the Application object, with the application in this case being the IE instance itself.) Even controls which were rendered to the control calling the method are affected -- in the case I tested, a control which was already rendered in the IE window prior to the control calling EnableVisualStyles() repainted itself to use the XP styles, which it wasn't using when it was initially painted.

This isn't a major concern since my company's controls will be the only Windows Forms controls in any IE window where they appear, so inadvertently affecting any 3rd-party controls which might be present on the page shouldn't be an issue. (And generally, using the functionality of IE hosting WinForms controls at all seems to be a pretty rare practice!) We will need to be careful to coordinate the change among our own various controls, though, to make sure everything looks right when using the new styles.

Update 8/18/2006: This morning, I tested the same control using Internet Explorer 7 (beta 3), and it also does display the XP styles/themes. (I did hit a snag where at first, I thought that it wasn't working in IE7; however, this was because the test machine where IE7 was installed was set to have XP styles disabled OS-wide. When I enabled XP styles in the operating system display settings, the control as displayed in the IE7 window immediately updated to use the XP styles.)