Last Comment Bug 393823 - -osint logic not written out to the windows registry when using software update on the 1.8.0 branch
: -osint logic not written out to the windows registry when using software upda...
: fixed1.8.0.14
Product: Thunderbird
Classification: Client Software
Component: Security (show other bugs)
: 2.0
: x86 Windows Vista
-- normal (vote)
: ---
Assigned To: Scott MacGregor
Depends on: 389613
  Show dependency treegraph
Reported: 2007-08-26 22:26 PDT by Scott MacGregor
Modified: 2007-12-03 15:57 PST (History)
6 users (show)
dveditz: blocking1.8.0.14+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

brute force fix (1.35 KB, patch)
2007-08-26 22:27 PDT, Scott MacGregor
mozilla: superreview+
dveditz: approval1.8.0.14+
Details | Diff | Splinter Review

Description User image Scott MacGregor 2007-08-26 22:26:55 PDT
spinning out from Bug 389613. 

Stephen and I actually put a bunch of comments in Bug 389613 over the weekend, but we really should have broken this issue out into a new bug for triage purposes so I'm doing that now.

"Stephen identified a problem with this fix. On the 1.5.0.x branch, we compare
the application path and nothing else when determining if the app is still the
default. Thus, a user who is running as the default and gets upgraded
to, won't get the osint flag written out to the registry for the
appropriate keys. You need to unset, then set Thunderbird as the default mail
client for the keys to get written out.

This isn't a problem when testing: and using clean VMs for each test. and a debug with the fix.

Note: the behavior of detecting default client status based on the application
path and not the command line arguments as well has changed on the 1.8.1 branch
so this isn't an issue there. It's specific to 1.8.0."
Comment 1 User image Scott MacGregor 2007-08-26 22:27:50 PDT
Created attachment 278375 [details] [diff] [review]
brute force fix

Same comment I put in Bug 389613:

"Here's a fix that seems to address the spot where the default client status
isn't changing, causing us to fail to write out the osint flags.

It's a brute force approach for sure, but this is for the 1.8.0 branch only,
and this approach has a lot less risk than modifying the different ways in
which we detect default app status for mailto, news, nntp, snews and feed urls.

Every time 1.5.0.x starts up, for each protocol the current application
instance is the default for, re-write out the registration keys. And re-write
out the protocol key giving us default status with the OS."
Comment 2 User image Scott MacGregor 2007-08-26 22:28:46 PDT
Repeating the testing comments over in:

Here's what I did to test the brute force patch:

(either a clean VM or make sure the mailto, nntp, news, feed and snews keys
don't have -osint already in the registry)

1) Downloaded a nightly build from before the original fix went in
like this one:

2) Make sure this installation is the default mail, news and feed client.

3) Verify that the test case still fails and the profile manager comes up.

4) Now check for updates and get updated to the latest update.

5) Restart to install the update

6) Quit thunderbird

7) you can manually inspect HKLM\mailto, HKLM\news, etc. to see that the -osint
is now written out into the registry.

8) Run the test case again and verify that nothing comes up.
Comment 3 User image Scott MacGregor 2007-08-26 22:29:54 PDT
and since I temporarily checked in the brute force patch onto the branch so we could test it this weekend, here are Stephen's findings copied from

I can *finally*, *truly* verify this bug as fixed, using Scott's instructions
in comment 49, above.

C:\PROGRA~1\MOZILL~1\THUNDE~1.EXE -osint -compose %1 gets set under:

My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Mozilla

Using the pre-fix build (2007-07-31-06 of mozilla1.8.0), I see the Profile
Manager invoked when running the testcase in comment 43.  Post-fix, after
upgrading to 2007-08-26-04, I can see that not even the compose window comes
up, which I think is the expected outcome given Scott's step #8 in comment 49.
Comment 4 User image Daniel Veditz [:dveditz] 2007-09-06 11:20:03 PDT
Does this hack need to go into Tbird 2.0 as well, or is it just an issue with 1.5-era installers?
Comment 5 User image Scott MacGregor 2007-09-06 11:52:15 PDT
This is just for 1.5 Dan. 
Comment 6 User image Scott MacGregor 2007-10-03 13:12:49 PDT
Comment on attachment 278375 [details] [diff] [review]
brute force fix

asking David for an sr on this brute force patch which is currently on the 1.8.0.x branch to make it easier for QA and others to help verify the fix.
Comment 7 User image Daniel Veditz [:dveditz] 2007-12-03 15:57:06 PST
Looks like the "temporary" landing is still there, and we're going to take it anyway so marking fixed on the branch.
Comment 8 User image Daniel Veditz [:dveditz] 2007-12-03 15:57:39 PST
Comment on attachment 278375 [details] [diff] [review]
brute force fix

approved for, a=dveditz for release-drivers

Note You need to log in before you can comment on or make changes to this bug.