recent regression --this was working in 2001.06.19.xx bits. currently see this in 6/21 am comm verif bits on win32 and mac [no linux build yet]. 1. launch profile manager. 2. select a profile [click on it]. 3. hit enter key. expected: profile should then launch. actual result: nothing happens. non keyboard workaround: click Start Netscape 6 button. keyboard workaround: hit tab till the Start Netscape 6 button has the focus ring, then hit the spacebar.

also noticed that doubleclicking the selected profile name in the prof mgr no longer works. and, also confirming that this is also a problem on today's linux bits.

*** Bug 87488 has been marked as a duplicate of this bug. ***

console output from 6/21 linux debug, when i hit enter key [unsure if it's relevant]: ProfileManager : StartApprunner profileName passed in: testing WARNING: CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///u/sairuh/.mozilla/testing/z5vvp2v1.slt/chrome/userChrome.css' failed. Error code: 18, file nsCSSLoader.cpp, line 1539 no console output when i doubleclick the profile name, other than ProfileManager : StartApprunner profileName passed in: testing

Worse than minor, I think, since it's so common to just hit 'Enter' to get past the profile picker.

This is ***SOOOooooo*** aggravating. It is wasting my time. I expect the default page to have loaded, but no, I still have the profile picker since it isn't accepting my keyboard input. Please fix this!!!!!!!!

Broke with Conrad's 6/19 checkin to profileSelection.js. The window is no longer closing, so even though we're calling startApprunner, startup won't proceed. --> conrad

Looking at it. startApprunner is mis-named. It has never really done that. What has changed is that the calls to AppShell::Quit are gone. They were causing bad things to happen which was why this was changed. The window is now put up with windowwatcher instead of Appshell:Run(). Question is, if clicking the "Start" button dismisses the dialog, why don't double-click and enter? Shouldn't any of these events end up calling the onStart() in profileSelection.js? And, if so, why does the button click continue on to close the window?

Alright - need some help from somebody knowing more about XUL than I. First off, this can be solved by calling window.close after calling startApprunner. The profile is indeed set - the window is just not closed. My question is: why is the explicit close() needed? If I dump something so I can see if doOKButton in dialogOverlay.js is being called, it is called on clicking the button but not on hitting enter or double-clicking. Anybody know why this is? Does the profile dialog need to do some further setup so this happens? Or, is calling window.close sufficient?

It's because dialogOverlay.js closes the window after calling the dialog's OK function (http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/dialogOve rlay.js#26). So yeah, we need the explicit close, otherwise nothing is telling the window to close... While you're at it, remove that case for 13 in HandleKeypress, and change the id of the keyset in profileSelection.xul to dialogKeys. That will make enter hook in to the button automatically (and make Escape work). We still need the explicit window.close() for the double-click case, though. If you want, you could put the window.close() after the onStart() call in HandleClick.

Thanks. Doing it.

The patch fixes it. Esc, Enter, & double-click work. Kathy, Blake - Can you r=/sr= ?

BTW - anybody know what the "fooKey" is about?

The patch fixes the problem in my linux tree.

setting milestone to 0.9.3 (I hope that's the right one). In profileManager.js, the open/close braces seem to be on new lines; please change your fix to be consistent within that file. I'm not sure about this but, in profileSelection.xul, maybe you should not remove the keyset line. Instead you should be just adding: <keyset id="dialogKeys" /> I'm not the module owner here though, so I'm not really sure what the intent is. r=brade

With the exception of one switch statement, the braces in profileManager.js are on the same line. > <keyset id="dialogKeys" /> > I'm not the module owner here though, so I'm not really sure what the intent is. The intention is to use dialogKeys as the keyset so that enter and escape work as expected without explicitly handling them in HandleKeyEvent. And then, still leave the "fooKey" in place.

sr=blake No clue what the fooKey is, I was wondering that myself. Probably something ben (or someone) was using to test, I think we should remove it...

Fix checked in.

i noticed this was fixed on the trunk [at least when i was looking at trunk bits from last week]. i take it this hasn't been checked in yet on the branch? it's still an issue using 2001.07.02.0x-branch comm bits on all/all. cannot remember if this should be reopened till it's checked in both places [since it has nsBranch]...

adding vtrunk keyword to indicate the bug has been fixed on the trunk. Bug left open for tracking checkin to branch (nsbranch) when appropriate. Once bug has been fixed on the branch also, pls remove vtrunk keyword.

*** Bug 89048 has been marked as a duplicate of this bug. ***

*** Bug 89108 has been marked as a duplicate of this bug. ***

yes, needs branch checkin.

Fixed on branch as well.

verified on branch 2001071008

According to bug 95863, this is still broken on Mac.

When this fixed was checked in, it certainly was working on the Mac. Something else may have happened in the meanwhile though.