To enable DDE, Toolkit/XPFE create registry keys in a location usually only writable by administrators. This thus breaks under a LUA. Why aren't these keys written to HKEY_CURRENT_USER\Software\Classes instead of HKEY_CLASSES_ROOT? A side effect of this is that if e.g. Firefox crashes under an administration account, it behaves flacky when resuming a session under a LUA until run as administrator again (see bug 340583).

bug 154238 comment 5 i warned about this a *long* time ago.

Mozilla is the only app I know of that uses this hack. It would be better to fix our DDE implementation than to improve on the existing hack in order to workaround this problem. bug 353089 is for the fixing / removal of the add / delete ddeexec keys hack.

Fixed by the checkin of the patch in bug 353089. You might be prompted to set as default browser which will reset the dde registry keys to their new values.

note: though this was not one of the Vista bugs this bug had to be fixed to fix other Vista bugs.

v.fixed with Firefox 2.0.0.2 rc2: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070208 Firefox/2.0.0.2, compared registry keys created/deleted by 2.0.0.1 on startup/shutdown with those created by Firefox 2.0.0.2 rc2, and the ddeexec keys are set in the right places and remain set on shutdown. NOTE: I was also able to verify that the error message I see with 2.0.0.1 when trying to launch a URL by a Limited user (window still opens), after installing and setting browser default as Admin user...is gone with 2.0.0.2 rc2.