Open Bug 250675 Opened 20 years ago Updated 2 years ago

Need more descriptive error message when user does not have permissions to modify default mail/news program under HKLM in the registry

Categories

(Thunderbird :: Preferences, defect)

Product:
Thunderbird
Component:
Preferences
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

People

(Reporter: mfedyk, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707 Firefox/0.8
Build Identifier: Thunderbird 0.7.2 (20040707)

On one system for a user who used to have power user permissions but was reduced
to regular user permissions, now requires power user permissions again to set
the default mail application.

With regular "user" permissions thunderbird, when trying to uncheck the
"thunderbird as default mail application" perf checkbox, it gives a message
saying I don't have permission.

If I add the user to "power users" group, and repeat, there are no errors.  Then
removing the user from the "power users" group leaves the pref intact.

I can reproduce on this machine every time, but not on mine with my user.  I
haven't tried any other users on this machine though.

The goal is to get the send to -> mail recipient context menu to work by
creating a message with that file attached (usually used for sending PDF files).

Reproducible: Sometimes
Steps to Reproduce:
1.
2.
3.
OK, more on reproducing.

It seems that my account on my computer already had Power User rights, so that's
why it works here.

I have yet to create a restricted (only "user" rights) account and test it under
those circumstances.
This is a problem with the way default clients are implemented under WinXP (and 
Win2K-SP3+).  It's not possible to set the default on a per-user basis, because 
the OS support for determining the default always refers to the (global) HKLM 
branch of the registry; values store in the user-specific HKCU branch is almost 
entirely unsupported.  
This is apparently a bug in the OS -- see bug 220865 comment 6.

Writes to the HKLM branch are generally restricted to Power Users or Admins.  I 
don't think there's anything Mozilla can do about -- you can't make *any* client 
a default browser/mailer/whatever without those privs.
from bug 220865 comment 6:
"Mozilla Mail/News already does create the HKCU branch, but as far as I can tell 
it is ignored thereafter, by Windows and by Mozilla."

So then let this bug mean "set HKLU (for when the windows bug is fixed in some
future patch or OS version), and give descriptive error/warning that the global
setting failed."
Summary: Unsetting thunderbird as default mail application requires power user or admin permissions → Need more descriptive error message when user does not have permissions to modify default mail/news program under HKLM in the registry
Depends on: 247869
> "Mozilla Mail/News already does create the HKCU branch, but as far as I can
> tell it is ignored thereafter, by Windows and by Mozilla."

Actually, I've since determined that Windows (Win2K-SP3, anyway), and IE6 both 
abide by the HKCU setting for the default mail client, as far as sending mail 
via MAPI.  I don't have XP so I don't know how this affects the Start menu.  
Other Windows apps, however, don't necessarily do so; Word 2000, on my system, 
always determines the mail client via the HKLM branch.

Also, I see in the source that Mozilla MailNews *does* use the HKCU branch to 
determine if it's the default; see bug 245532.  The patch at that bug removed 
that check for TB (still awaiting trunk check-in) due to the problem that other 
clients don't write to HKCU, so the program thinks it's the default when it's 
not.

The more descriptive error would be very useful, but the logic of this whole 
operation needs work.
My situation is complex because I've got an older version (0.9) running 
"installed" and a newer version (currently 1.0RC1) that's simply been extracted 
from the zip archive.  I started running like this after 0.8 was released; I had 
0.8 installed and various pre-9 nightlies unzipped.  At that time, I had 0.8 set 
as the default mail client, and would simply tell the nightly build No every 
time it asked to be the default.  So long as I did this, 0.8 never re-prompted 
me.

A few days after updating to 0.9 as an installation (and setting it as default), 
I unzipped a post-9 build for testing.  I decided to make the test build the 
default.  Since then, no matter which version I ran, I would be prompted to make 
it the default; and no matter which answer I gave to either version, the prompts 
continued.

I finally got around this today by running 1.0RC1 *as Administrator* -- then I 
said, Yes, be the default.  Since then, running 1.0RC1 (as any user), I am not 
prompted; running 0.9, I am.

The weird thing is: my normal account has Power User privs and is allowed to 
write to the HKLM registry branch; this wasn't doing the job, and in fact I 
examined the registry and it looked to me like everything was set up as I would 
have expected.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I see a lot of anecdotal evidence in the other bugs on this issue that there are
several aspects (and applications) of this issue tha do respect the HKLU branch
setting in the registry.  Though, it might not be *every* application that does.  

Mcow, I suspect the problem is that TB is testing for more than it is setting or
able to set as a power user.
Bug 279627 is about this symptom now occurring with the suite's MailNews 
component.
Bug 277833's patch was checked in that moved TB's Windows-integratioin into the 
trunk, and may have caused this problem.

Scott, can you comment?
*** Bug 277182 has been marked as a duplicate of this bug. ***
*** Bug 268839 has been marked as a duplicate of this bug. ***
Note that a patch was checked in this morning for bug 279627, which exhibited a 
similar symptom in the Suite.  (That bug was entered shortly after the registry 
access code for Thunderbird was backported to the trunk.)

The patch does not concern admin rights, but fixes a bug which caused some 
installations to fail writing out the keys even where the user's rights were 
sufficient.  Some bugs duped to this may have actually been about the problem 
that was fixed there, rather than this bug's problem.  Builds ("nightly" 
*untested* builds) with the patch should be available tomorrow at:
  http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/
I finally got around to checking out the behavior of TB since bug 279627's patch 
was installed.  I repeated the sequence of operations from comment 5: had 1.0.2 
installed, then unzipped a 1.0+ and ran it; when it asked to be made default, I 
said Yes (with normal Power User privs) and the setting took.

So my problem, at least, was fixed (I believe by the patch in bug 279627).  

I wanted to see what would happen for unprivileged user, so I created such a 
user, logged in, and started up TB 1.0.2 while the 1.0+ was the system-wide 
default.  Result: no prompt!

So I tried setting the default status via the Options dialog.  Result: an error 
saying "Thunderbird could not update the registry key... check with an 
Administrator..."

Next, I logged in as Admin and made 1.0.2 the default; then I relogged in as the 
vanilla user and started the 1.0+ version.  Same results: no prompt at startup, 
and if explicitly attempted to change the setting, got an explicit error saying 
why it didn't work.

So I think this bug should be WFM'd -- I don't know exactly which patch added 
the error message about inability to update the registry, it might have been a 
patch filed under Firefox.
(In reply to comment #11)
> I finally got around to checking out the behavior of TB since bug 279627's
> patch was installed.  I repeated the sequence of operations from comment 5:
> had 1.0.2 installed, then unzipped a 1.0+ and ran it; when it asked to be
> made default, I said Yes (with normal Power User privs) and the setting took.

I need to recant this.  A subsequent retest showed that the Default Client 
setting would not stick when run as as Power User.
*** Bug 304062 has been marked as a duplicate of this bug. ***
Suite bug 235660.
*** Bug 332216 has been marked as a duplicate of this bug. ***
QA Contact: preferences
Assignee: mscott → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.