enter or doubleclicking no longer launches profile

VERIFIED FIXED in mozilla0.9.3

Status

SeaMonkey
Startup & Profiles
VERIFIED FIXED
17 years ago
13 years ago

People

(Reporter: sairuh (rarely reading bugmail), Assigned: Conrad Carlen (not reading bugmail))

Tracking

({access, regression})

Trunk
mozilla0.9.3
access, regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: PDT+)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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.
(Reporter)

Updated

17 years ago
Keywords: access, regression
(Reporter)

Comment 1

17 years ago
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.
Summary: enter no longer launches profile → enter or doubleclicking no longer launches profile
(Reporter)

Comment 2

17 years ago
*** Bug 87488 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 3

17 years ago
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

Comment 4

17 years ago
Worse than minor, I think, since it's so common to just hit 'Enter' to get past 
the profile picker.
Severity: minor → normal

Comment 5

17 years ago
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!!!!!!!!
Keywords: nsCatFood

Comment 6

17 years ago
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
Assignee: blake → ccarlen
(Assignee)

Comment 7

17 years ago
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? 
Status: NEW → ASSIGNED
(Assignee)

Comment 8

17 years ago
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?

Comment 9

17 years ago
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.
(Assignee)

Comment 10

17 years ago
Thanks. Doing it.
(Assignee)

Comment 12

17 years ago
The patch fixes it. Esc, Enter, & double-click work.
Kathy, Blake - Can you r=/sr= ?
(Assignee)

Comment 13

17 years ago
BTW - anybody know what the "fooKey" is about?

Comment 14

17 years ago
The patch fixes the problem in my linux tree.

Comment 15

17 years ago
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
Target Milestone: --- → mozilla0.9.3
(Assignee)

Comment 16

17 years ago
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.

Comment 17

17 years ago
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...
(Reporter)

Updated

17 years ago
Keywords: nsBranch
(Assignee)

Comment 18

17 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 19

17 years ago
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]...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: needs branch checkin?

Comment 20

17 years ago
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.
Keywords: vtrunk

Comment 21

17 years ago
*** Bug 89048 has been marked as a duplicate of this bug. ***
*** Bug 89108 has been marked as a duplicate of this bug. ***

Comment 23

17 years ago
yes, needs branch checkin.
Whiteboard: needs branch checkin? → PDT+
(Assignee)

Comment 24

17 years ago
Fixed on branch as well.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 25

17 years ago
verified on branch 2001071008
Status: RESOLVED → VERIFIED

Updated

17 years ago
Keywords: vtrunk

Comment 26

17 years ago
According to bug 95863, this is still broken on Mac.
(Assignee)

Comment 27

17 years ago
When this fixed was checked in, it certainly was working on the Mac. Something
else may have happened in the meanwhile though.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.