paulmac suggested i file this bug, since you were the one who fixed a similar problem with the Prefs dialog (bug 22213). definitely a problem on windows (NT, with 2000010408 comm. bits) and Mac (OS 9.0, w/2000010409 comm. bits). doesn't seem to be a problem with the linux build (2000010409 comm. bits). to repro: 1. bring up the Open Web Location dialog. 2. type something in the text field (eg, www.mozilla.org). 3. hit Esc to Cancel, or Enter/Return for OK. expected: if i hit Esc, the dialog should go away. if i hit Enter/Return, the dialog should go away followed by the browser going to that url. results: nothing happens either way --the dialog remains up. alas, on the windows end nothing useful appeared (ie, no output at all) in the dos console (and there's no console on mac, afaik). however, since it worked on linux, this is what i saw there: bring up dialog and hit Esc: ---------------------------- WEBSHELL+ = 7 change lock icon to unlock - new document nsXULKeyListenerImpl::Init() Move window by 0,80 screen x 0screen y 0 WEBSHELL+ = 8 ! nsSecureBrowserUIImpl found: chrome://navigator/content/openLocation.xul change lock icon to unlock ?(chrome 0) WEBSHELL- = 7 WEBSHELL- = 6 bring up dialog and hit Enter: ------------------------------ WEBSHELL+ = 7 change lock icon to unlock - new document nsXULKeyListenerImpl::Init() Move window by 0,80 screen x 0screen y 0 WEBSHELL+ = 8 ! nsSecureBrowserUIImpl found: chrome://navigator/content/openLocation.xul change lock icon to unlock ?(chrome 0) nsLayoutHistoryState::AddState OOPS!. There was already a state in the hash table for the key change lock icon to unlock - new document WEBSHELL- = 7 WEBSHELL- = 6
spam: reassigned QA to me.
This is working on the Mac with a build from 1-5-2000. Please confirm that the bug still exists on Windows or I will have to mark it as works for me.
Summary: Open Web Location doesn't respond w/Enter & Esc keys for OK & Cancel → Open Web Location via shortcut doesn't respond w/Enter & Esc keys for OK & Cancel
tested with 2000010508 (comm. bits) on mac, linux and winNT, and what i found today is that the hitting Esc or Enter/Return fails (ie, does nothing) if i had brought up Open Web Location via the keyboard shortcut (Cmd/Alt/Ctrl+L). however, if i bring up that dialog by going to the menu and selecting File > Open Web Location (with a mouse), somehow the dialog decides to respond as expected to the Esc and Enter/Return keys. side note: doesn't seem to matter whether or not i click the pointer in the dialog or its location text field... anyhow, updated summary to reflect this. let me know if there's other stuff i could do to narrow this one down. thx!
M14 since Paul is out sick
seems to work ok now. Using 2000-01-27-15 on Windows NT.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME
this is still a problem with me: using 2000-01-31-08 (tho' this is a bad build for any testing of dialogs :-P) on winNT (comm) and linux (non-comm). reopening. the key to repro'ing this bug is that the Open Web Location dialog needs to brought up via the keyboard shortcut (Ctrl+L/Alt+L). this is not a problem when access that dialog via the menu (File > Open Web Location...).
Status: RESOLVED → REOPENED
This bug seems to have mutated into a key binding bug. Sending to Chris per his suggestion.
Assignee: hangas → saari
Status: REOPENED → NEW
Target Milestone: M14
Wow, I have no idea why there would be a difference in the dialog behavior depending on how you open it... CC'ing hyatt because my gut says this is a XBL/keybinding issue
This bug scares me, raising priority
Priority: P3 → P1
*** Bug 27813 has been marked as a duplicate of this bug. ***
Okay PDT people, this bug is driving me nuts so I'm nominating it
Fixed, thanks Hyatt!
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago → 19 years ago
Resolution: --- → FIXED
yay! verif w/opt comm bits  on linux, mac and winNT.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.