Many of our customers are large, global organizations with hundreds of thousands of employees and thousands of locations. With such a vast infrastructure, their IT organizations take great pains to keep their computers stable and secure. While in theory only 2.4% of the United States is using IE6 (see http://www.theie6countdown.com), large corporations are keeping it alive and well because it is so complicated for them to upgrade.
Part of what makes upgrades take so long is that the corporations need to test out their customized desktop configurations with all of their applications. While Windows 7 and IE8 work great out of the box, many large companies will adjust the security policies to restrict what employees can do. Windows 7 and IE8 have a whole new set of security settings, and this leads to a whole new potential for bugs.
One client came to us saying that their users were no longer able to print using CTRL+P when they were running Windows 7 and IE8. I run Windows 7 and IE8 myself, and we weren’t having any issues, so we set up a live desktop share so that we could observe what they were seeing.
Their security settings had disabled many settings like the menus and toolbars, so unless a screen offered a specific “print” icon in the page, CTRL+P was the only option. On some screens, CTRL+P worked fine, but on others nothing happened; the print dialog wouldn’t appear. For me, on my normal installation, it was working fine.
I took control and tried poking around. I found that if I clicked around enough times, eventually the CTRL+P would start working, although it wasn’t clear why. Finally, I figured out that if the focus changed from the page itself to an element on the page, like an anchor, it would work. A simple workaround was to just hit “tab” to change the focus to an element, but we needed to find the root cause. I used the developer tools built into IE8 to check where the focus was at page load (go to the script tab, and enter document.activeElement), and found that the focus was on the BODY element, just like you would expect, and just like mine. What was different?
As an experiment, we asked the client to create a blank instance without the modified security policies, and they confirmed that CTRL+P worked fine. That at least supported the theory that a security policy was the culprit. However, in reviewing all of the policies they had altered, none seemed like a good candidate. We asked them to start activating security policies in groups until the right one could be found.
The first surprise was even with all of the IE8 security policies back in place, CTRL+P still worked fine. The cause wasn’t one of the IE8 policies itself; it was therefore one of the ones for Windows 7.
In the end, the culprit was found to be “Remove File Menu in Windows Explorer”. Really?
While I would never have guessed it would be the source of the problem, in retrospect, it does make a certain sort of sense. The “CTRL+P” option lives inside of the File menu, so I figure that when the file menu was removed, the default accelerator was no longer available. When the focus was changed, there must have been some other “path” to a CTRL+P option.
Why did it affect Internet Explorer, given that the setting is supposed to affect just Windows Explorer? Also not clear, although I am guessing that it goes back to the deep connection between Windows Explorer and Internet Explorer when IE was first released. Remember the Netscape lawsuits? They must still share some settings.
At any rate, problem solved.
