Open Web Location via shortcut doesn't respond w/Enter & Esc keys for OK & Cancel

VERIFIED FIXED in M14

Status

()

Core
XUL
P1
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: sairuh (rarely reading bugmail), Assigned: saari (gone))

Tracking

Trunk
x86
Other
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+])

(Reporter)

Description

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

Updated

18 years ago
QA Contact: paulmac → sairuh
(Reporter)

Comment 1

18 years ago
spam: reassigned QA to me.

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M13

Comment 2

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

Updated

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

Comment 3

18 years ago
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!

Updated

18 years ago
Target Milestone: M13 → M14

Comment 4

18 years ago
M14 since Paul is out sick

Comment 5

18 years ago
seems to work ok now. Using 2000-01-27-15 on Windows NT.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 6

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

Updated

18 years ago
Resolution: WORKSFORME → ---

Comment 7

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

Comment 8

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

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M14
(Assignee)

Comment 9

18 years ago
This bug scares me, raising priority
Priority: P3 → P1

Comment 10

18 years ago
*** Bug 27813 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 11

18 years ago
Okay PDT people, this bug is driving me nuts so I'm nominating it 
Keywords: beta1

Updated

18 years ago
Whiteboard: [PDT+]
(Assignee)

Comment 12

18 years ago
Fixed, thanks Hyatt!
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 13

18 years ago
yay! verif w/opt comm bits [2000021808] on linux, mac and winNT.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.