User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916 Currently, when I set Mozilla as my default browser (from initial startup, or File-Preferences-Advanced-System) it should include *.htm as well as *.html. The later is done, but the former isn't. Reproducible: Always Steps to Reproduce: 1. Set Mozilla as default for HTML Documents 2. If a different browser was previously default, it will still be default for *.htm with Mozilla now being default for *.html

I can't reproduce this, with a nightly build from 2003091510 (win2k), and the code in question doesn't look like this bug would be possible... unless maybe the .htm registry key has an ACL that forbids changing it, of course

Not being familier with ACL's on registry keys under Win XP, could you tell me what I should look for to see that is the problem?

I can only describe it for win2k, I hope it's similar on winxp: 1. run regedt32.exe (not regedit.exe) 2. find HKEY_CLASSES_ROOT\.htm 3. choose Security|Permissions (not 100% sure if it's called that, I have a german version) 4. check in the resulting menu if you have enough access to change values in there. alternatively, just try to change the Default value there (for this, you could use regedit too, if you prefer)

OK, that is close to what Win XP has. HCR/.htm has both "Full Control" and "Read" set to "Allow". This includes Administrator, and the user (that being me) who installed Mozilla. I note that .htm has "(Default)" set to "htmlfile", while .html has "(Default)" set to "MozillaHTML".

.htm also has MozillaHTML for me... maybe this is something winxp-specific... as I said, this works for me on win2k, so I unfortunately can't help with this bug :(

In Comment #1 you mentioned code you looked at. Which code was that? If it is Win XP specific, then I'll need to do some serious investigating...

I looked at xpfe/components/winhooks/nsWindowsHooks.cpp especially http://lxr.mozilla.org/seamonkey/source/xpfe/components/winhooks/nsWindowsHooks.cpp#95

Good, I was looking in the right place. I note that ACL is checked by creating a key in HKLM/SOFTWARE, which for me might fail depending on how Microsoft does inherited access rights on Win XP. As a user I have read access, and as a member of Administrator group I have full access. However, that ACL check isn't 100% as the keys that are failing on my machine are in HKCR. Or, in other words, a users access to HKLM has no relation to their access to HKCR.

Hmmm, interesting. What's the difference between HKCR\.htm and HKLM\SOFTWARE\Classes\.htm ? On the second one, everything is set as it should be.

HKCR is affected by current user settings HKLM is local machine global settings which can be clobbered by local settings. mozilla probably doesn't handle this stuff correctly. This shouldn't surprise anyone since a good interface for this is pretty hard to design. If someone is interested in playing with the code, here's what I'd suggest: If there are HKCU/HKCR values and the user asks to set things, only set them. If there aren't, try setting HKLM values. If that fails, set HKCU values. This means that an admin w/ custom values will have to delete them with regedit/regedt32 before trying to use mozilla to set the global settings to mozilla. I think this is a reasonable compromise. I can write this code, or help someone write this code if the hints i've given aren't sufficient.

Well, I'm tempted to offer, but I'm currently trying to focus on the reason behind my main problem. Now, that may end up leading to a rewrite, and that's OK as by then I'll understand more of the codebase involved. Another question. When one installs Mozilla, registry values are set (assuming one agrees to Mozilla being the default browser) along with the .htm and .html settings. Now, if someone uses Edit-Prefs-Advanced-System to say that Windows should use Mozilla for "HTML Documents", does this use the same code for registry settings as the install process uses? Also, what about the "Set Default Browser" button in Edit-Prefs-Navigator?

>does this use the same code for >registry settings as the install process uses? Also, what about the "Set Default >Browser" button in Edit-Prefs-Navigator? all of them share the same code. the "install process" does not set the default browser, that is done on first launch of the browser.

OK, I know from experimentation last night that something is changing HKCR/.html but is ignoring (or failing on) HKCR/.htm. Hmmm, I should've checked the HKLM values at the same time. Oh well, another task for debugging/testing. As all processes use the same code, that will make my debugging easier as I don't need to worry about duplicate code (unless I find some that is).

Maybe regmon, available from http://www.sysinternals.com, will be able to help you.

RegMon is an excellent tool, for this problem anyway. It is very verbose which some might consider a pain, but is excellent for fixing Mozilla and Windows Registry. Many thanks for pointing it out to me. I have determined that the code in nsWindowsHooks.cpp that checks if the user can create a Registry key is not needed as Mozilla has already created several keys (mainly for crypto, but also for other things). So, as I intend to fix that part at least, I'm taking the bug.

OK, there are two files/modules that setup defaults in the Windows Registry on startup. mozilla/xpfe/components/winhooks/nsWindowsHooks.cpp which is driven by a seperate process, and I also found mozilla/mailnews/mapi/mapihook/src/nsMapiRegistryUtils.cpp Again, thanks go to the RegMon tool, as without it I wouldn't have found the mailnews process. I'm still tracing the process flow (as well as several unrelated items) so this will take a bit of time.

As far as I can tell, Timeless isn't receiving stuff from this bug, so adding to cc list (based on his interest to help in Comment #10). Remove as needed.

OK, this code (nsWindowsHooks.cpp and nsWindowsHooksUtil.cpp) is full of bugs, including mismatched 32-bit and 16-bit function calls, and duplicate #include's (including a possible recursive include). I'm also getting closer to where this bug is happening.

OK, I've found a fix (although not the faulty code). What happens is that when the Windows Registry has an existing HKEY_CLASSES_ROOT\.htm which has a subkey called "OpenWithList" (which itself is full of subkeys), then the bug occurs. However, when I remove the .htm key (or rename it), then a new .htm key is created with (Default) set to MozillaHTML as it should be. Now to find out why that subkey causes this bug.

This removes the Registry authority check code from mailnews as registry has already been written to before we hit this code, and the authority check isn't worth it as each key in the Windows Registry can have a different authority level. Having write access to HKLM doesn't imply that you have write access to HKCR or anything else.

Hmmm, I found an interesting article at MSDN. http://msdn.microsoft.com/library/en-us/sysinfo/base/hkey_classes_root_key.asp HKCR is primarily used to maintain compatibility with 16-bit Windows machines. Thus, to fix the code, I think all we need to do is remove any HKCR settings that might affect us, and ensure that HKLM/Software/Classes and/or HKCU/Software/Classes are set appropriately (keeping comment #10 in mind). I'm going to assume that access to HKLM is controlled by the Admin user and thus trying to set it may fail due to access rights.

The problems with the .htm key in HKCR has additional reprecussions in additions to Mozilla not handling .htm as it should. I found that it can affect how programs such as FrontPage "see" the default browser. A week ago, I accidentally set IE back to the default browser when I had to use it to test a web site. I set Mozilla back to the default, but noticed that it didn't retake the .htm extension as it did before. Also, FrontPage no longer adknowledged Mozilla as the default browser when I previewed a page. It had reverted back to using IE. After deleting the .htm key in HKCR, I was able to fix both of the above problems.

My current thoughts on the fix for this bug is to get rid of the existing code that creates/deletes/modifies the registry entries in the Mozilla Suite, and replace it with the code that is used by Firefox (et.al.). That will clean up the code and make it easier to follow. However, it does involve moving from c++ to javascript.

eh, firebird forked this code?

As far as I can tell it did (well, not so much a fork, as a total rewrite). It uses code in mozilla/browser/installer/windows/

what does installer have to do with this?

There are two aspects to this bug. 1/ Where .htm isn't "set" when application is installed and user requests Mozilla/whatever to be the default browser. 2/ Where .htm isn't "set" when user requests it to be in Advanced-System.

so in firebird, it's really the installer which contains that code? (it's not in mozilla)

It seems that with Firefox, the Win Registry code is in the Installer component. I haven't found it anywhere else in Firefox, so I assume it was done that way to avoid code duplication. With Mozilla, it seems to exist in two places to cover the two sets of functionality (although both implementations are different from each other). Note: I haven't checked Thunderbird, Composer or Sunbird to see what they do.

(In reply to comment #21) > Hmmm, I found an interesting article at MSDN. > > HKCR is primarily used to maintain compatibility with 16-bit Windows machines. > Thus, to fix the code, I think all we need to do is remove any HKCR settings > that might affect us, and ensure that HKLM/Software/Classes and/or > HKCU/Software/Classes are set appropriately (keeping comment #10 in mind). This is a problem that affects a number of aspects of how the Moz programs interface to Windows. Not only are file extensions such a .htm affected, but so are protocols such as 'mailto' -- the handlers these are also specified in keys on the HKCR branch. I think saying "all we need to do is remove any HKCR settings" is naïve, but I agree that explicit writes to HKCR should be changed. The hard part is figuring just what to change them to. - First: you don't necessarily need to be an Admin, a Power User has write-privs to HKLM by default. - Second: I believe that you need to have write-privs in order to install any Mozilla tool, altho I'm not 100% sure about that. I know that I tried to install Moz1.5 on a Win2K system where I only had access to a User account, and it failed during the Gecko part of the install. - Third: Some people will be installing the program on their system and wanting to make it the default for everyone; other people will want to install it to make it available, but allow individual users to determine whether they want to make it the default. Those in the first group will want to be writing to HKLM, those in the second to HKCU. The situation gets trickier because Windows has the concept of the "default client" -- default mail client dates back to Win95, but default browser is WinXP (and Win2K-SP3+, altho that doesn't feature the Client UI on the Start menu). This setting is always global, in HKLM/Software/Clients; no OS support for that branch in HKCU (which apparently, for the later versions of the OS, is a bug -- see bug 220865 comment 6). But the protocol handlers (http, mailto) and the file associations (.html, .gif) and the default HTML editor are all specifiable on a per-user basis. Anyway, in general I agree that file associations should be made on the HKCU branch for Win2K/WinXP. However, the best way to handle this would be aware of the user's general access to HKLM, and involve confirmation of the several different sorts of changes that occur, with the user allowed fine-grained control over which changes are global and which are specific to the user. Even more involved would be UI to support the various cases where certain keys are protected, as seems to be the case here. (In reply to comment #19) > What happens is that when the Windows Registry has an existing > HKEY_CLASSES_ROOT\.htm which has a subkey called "OpenWithList" (which itself > is full of subkeys), then the bug occurs. However, when I remove the .htm key > (or rename it), then a new .htm key is created with (Default) set to > MozillaHTML as it should be. You probably do not want to remove the HKLM\.htm information, in particular OpenWithList. That key is used to determine which programs are listed in the Internet Options control panel, Programs Tab, "Default HMTL Editor" dropdown. (Mozilla properly installs itself as one of the subkeys of OpenWithList -- and then rather imperiously makes itself the default editor when it makes itself the default browser -- bug 196522). See also bug 35268. An HKCU\.htm\OpenWithList will be merged with the HKLM\.html\OpenWithList for reading from the HKCR version of the key.

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420