This does not affect the trunk for some unknown reason... perhaps a change in MSVC8. Changing the following in nsNativeAppSupportWin.cpp fixes this bug but is obviously wallpaper. If this is used #ifdef MOZ_PHOENIX should probably be added as well. Even if the app is still running removing this key does no harm though I suspect there is a slight perf impact. I have not been able to find any info about the DDECache reg key addition. // get rid of it as we are shutting down. // Note: Destroy calls DestroyWindow, which will only work on a window // created by the same thread. MessageWindow mw; mw.Destroy(); if ( mInstance ) { // Undo registry setting if we need to. - if ( mSupportingDDEExec && isDefaultBrowser() ) { - mSupportingDDEExec = PR_FALSE; #if MOZ_DEBUG_DDE - printf( "Deleting ddexec subkey on exit\n" ); + printf( "Deleting Firefox DDECache registry key on exit\n" ); #endif - deleteKey( HKEY_CLASSES_ROOT, "http\\shell\\open\\ddeexec" ); - } + deleteKey( HKEY_CURRENT_USER, "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\FileExts\\DDECache\\Firefox\\WWW_OpenURL" );

If we add support for Vista on the MOZILLA_1_8_BRANCH and don't have a real fix for this then we will have to do something along the lines of this patch. To test this patch the other Vista patches should also be applied (e.g. Bug 336469, Bug 353089, and Bug 353398 currently).

Comment on attachment 239845 [details] [diff] [review] branch wallpaper patch >+ // XXXrstrong - For Firefox on the MOZILLA_1_8_BRANCH we need to remove >+ // the DDECache WWW_OpenURL registry key which only exists on Vista. >+ // This is a noop when the key doesn't exist. See bug 353941. This is about the most useless comment possible. Why not explain *why* it needs to be removed? The bug sure doesn't have that information!

I previously stated in this bug that I don't know why this occurs on Vista beyond the fact that it is linked to this registry key. Also note that I stated "something along the lines of this patch", that I didn't request a review, and that there is a bug number referenced. If / when more info comes to light sure, I'll add more detail to the comment. For now, I prefer to provide a reference since the "reason" as well as the "details" as to why this is needed will most likely change. Isn't that reasonable?

Also note that I didn't take this bug. I'm hoping that if I don't figure out the reason why this occurs on Vista that someone else will and will take this bug.

You never stated you didn't know why it occurs, though it's obvious you're clueless on that from the other comments. I also did not question the bug reference, but instead the poor commenting practice of stating the obvious.

Sorry, I thought that was a given with the what I stated at the very beginning of comment #0, "This does not affect the trunk for some unknown reason...". I suspect you are also clueless since you have provided no insight as to why this is occurring... though your complaining without recommendations on how to fix this is very helpful.

If you had read what I said you'd know that I have not said anything about the code itself, only your poor commenting style, although hacking other applications' data is always bad karma. I have absolutely no incentive to look for why this bug is occurring or how best to solve it, thanks to the attitude of people like you. Even if I did know, you've happily put me off telling you.

No longer able to reproduce... WFM