Geoff Chappell - Software Analyst
Since Internet Explorer can run scripts that it finds in HTML pages, it is only natural that it supports a script debugger. Though Microsoft does not (nowadays) supply a script debugger with Windows, one is supplied with Microsoft Visual Studio and it is here assumed that some such debugger is already installed. Internet Explorer just has to notice and cooperate.
Internet Explorer ordinarily has script debugging disabled, presumably because there should be no need for it in ordinary use and few users anyway have the skills. A user-interface control is provided for enabling script debugging. Open the Internet Properties from Control Panel or from the Tools menu of Internet Explorer. Look on the Advanced tab, in a section headed Browsing, for a checkbox labelled “Disable script debugging (Internet Explorer)”. The checkbox may itself be disabled due to administrative policy. Otherwise, clearing the checkbox enables script debugging. If the checkbox was not already cleared, then although it is not among the settings that are marked “Takes effect after you restart Internet Explorer”, clearing it will not in fact take effect until Internet Explorer next starts—which is the first sign of the problem that causes this article to exist.
Given that a script debugger is installed and that script debugging is enabled for Internet Explorer, the way that Microsoft documents it as being supported is that Internet Explorer’s View menu should have a submenu labelled Script Debugger.
Very many ordinary-seeming operations, even without directly involving Internet Explorer, cause Script Debugger to vanish from the View menu.
Start Internet Explorer and verify that Script Debugger is on the View menu. Open Internet Options from the Tools menu. On the General tab, in the section headed Home Page, click the “Use current” button. Yes, it’s a pointless change. There are plenty of alternatives, but this one is the very first that you come across in the dialog box and it has the merit of emphasising the silliness. Click OK to close the Internet Options. Now refresh the page. A good demonstration is to do this from the View menu, since you will see that Script Debugger is still there before you click on Refresh. When the page has refreshed, look again on the View menu. Script Debugger is gone.
How does something so ridiculously simple go unnoticed at Microsoft, or noticed but not attended to? Make no mistake, the problem has been there for very many years, dating at least from the original Windows 2000. Could it be that nobody at Microsoft, or nobody with Microsoft’s ear, debugs client-side scripts by launching a script debugger from Internet Explorer? Could it even be that the behaviour just demonstrated is not a problem at all but is actually intended as the design?
It certainly is coded explicitly. The background to the cause lies in how MSHTML.DLL handles changes of configuration, particularly to update the MSHTML Options. These are not the only registry settings that MSHTML works with, but they are an especially important collection of settings and they include the two that determine whether script debugging is enabled. The tables that define these options for MSHTML specify that when updating the options, the ones for script debugging should not be re-read from the registry but should revert to defaults, which are that script debugging is disabled. Thus, do anything that updates the MSHTML Options, and MSHTML disables script debugging.
So, what things induce MSHTML to update these options? The simple answer is pretty much any change of configuration, from trivial to substantial. For instance, it’s enough just to click OK on any of the dialogs for Colors, Languages, Fonts or Accessibility, without having made any change. Also, the applicable changes are not just of Internet Explorer. For instance, change the screensaver, or even just its timeout interval, change the keyboard’s repeat delay, or change whether to hide inactive taskbar notification icons, and you lose script debugging from Internet Explorer. If this is by design, then it’s a laughably bad design.
Though this article is about Script Debugger getting lost from the View menu, it may help to have some details about the circumstances in which Script Debugger is even supposed to be on that menu.
Moreover, any program may use MSHTML for rendering HTML documents, including to interpret scripts. Internet Explorer is just one such document host, albeit by far the most typical. Any such host may offer to launch a script debugger. Internet Explorer has a Script Debugger submenu on the View menu, but other hosts may have other user interfaces. Underneath, whatever the host, it is MSHTML that has to believe a script debugger is installed and that script debugging is enabled.
MSHTML finds the script debugger through the registry using the class ID
| CLSID_ProcessDebugManager | {78A51822-51F4-11D0-8F20-00805F2CD064} |
Thus, the registry key HKEY_CLASSES_ROOT\CLSID\{78A51822-51F4-11D0-8F20-00805F2CD064} must exist and be properly configured for defining a COM class. As far as concerns MSHTML, the executable that is named by the default value of the InprocServer32 subkey is the script debugger.
Starting with the MSHTML.DLL from Windows XP SP2, and presumably also from some contemporaneous release of Internet Explorer, MSHTML allows that script debugging can be enabled or disabled separately for Internet Explorer versus all other programs. If the process is named IEXPLORE.EXE or EXPLORER.EXE, the relevant registry value is
| Key | HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main |
| Value | DisableScriptDebuggerIE |
| Type | boolean, as dword, binary or string |
| Default | true |
For all other processes, and in earlier MSHTML versions, the answer comes from the slightly different registry value
| Key | HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main |
| Value | Disable Script Debugger |
| Type | boolean, as dword, binary or string |
| Default | true |
Either way, MSHTML regards script debugging as enabled if the applicable registry value is present and evaluates as false. Specifically, the registry data must be the dword zero, or 4 null bytes of binary data, or the (case-insensitive) string false, no or 0.
Beware that a different interpretation applies to the user-interface support in the Internet Properties dialog box. It regards script debugging as enabled if the applicable registry value is present and is anything other than the string yes. Thankfully, it can be relied on to set the values only as yes or no, which must for consistency be recommended for all programs and users who think to set the values independently of Microsoft’s user interface.
The key that is listed above for both registry values is only the ordinary location. A document host can specify at run-time either or both of two different keys from which to read the value. The option key is a replacement location from which MSHTML is to read the value instead of reading from the ordinary key. The override key is an extra location at which to seek the value, with precedence over any value in whichever is used of the ordinary key and option key. For details, see MSHTML Options.
MSHTML version 7.0 introduces administrative control of the Disable Script Debugger value, i.e., the one for processes other than IEXPLORE.EXE or EXPLORER.EXE. The ordinary key, the option key and the override key are all ignored in favour of the keys
in decreasing order of precedence. Note however that recognition of the per-user policy can be defeated by a separate configuration of a registry value named Security_HKLM_only. For details, see MSHTML Options.
The per-user policy key has user-interface support through the Group Policy Object Editor, as “Turn on script debugging” in the Browsing category (under “Advanced settings” and Internet Settings) of the Internet Explorer administrative template (under Windows Components). This user interface sets the value only to the strings yes and no.
The user-interface support in the Internet Properties dialog box has its own thoughts about the policy keys. In particular, it allows that the DisableScriptDebuggerIE value may also be set as a per-user or machine-wide policy, even though MSHTML does not recognise policy keys for this value. A consequence is that the “Disable script debugging (Internet Explorer)” checkbox is disabled if this value is set in either of the policy keys. Another is that if the policy setting for this value is set to yes, then the checkbox will not only be disabled but checked, even though script debugging in Internet Explorer actually is enabled.
Provided that MSHTML believes that a script debugger is installed and that script debugging is enabled for Internet Explorer, the Script Debugger menu is inserted into the View menu immediately before the menu entry named Full Screen. The latter may be disabled, e.g., because of the NoTheaterMode registry value, but it is always present.
That something is not quite right with Internet Explorer’s support for debugging scripts is unsurprising from where Microsoft documents it. Not in any of Microsoft’s literature for either Internet Explorer or Windows have I found where Microsoft documents script debugging as a feature of Internet Explorer, such that one may debug scripts using an arbitrary script debugger.
Instead, Microsoft’s documentation is only with Microsoft’s script debugger. On the page How to: Debug a Client-Side Script from Microsoft Internet Explorer, users of Visual Studio are told what must be done in Internet Explorer to make the Visual Studio debugger usable for testing scripts in the environment in which Internet Explorer will run them. That is good, of course, as a reminder to Visual Studio users of what must be done in Internet Explorer, but it is not appropriate as the only notice that Microsoft gives to any users of Internet Explorer.