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

Status: VERIFIED FIXED

(Core :: XUL, defect, P1)

Description

[sairuh (rarely reading bugmail)]

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

Comment 1

[sairuh (rarely reading bugmail)]

spam: reassigned QA to me.

Comment 2

[hangas]

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.

Comment 3

[sairuh (rarely reading bugmail)]

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!

Comment 4

[Phil Peterson]

M14 since Paul is out sick

Comment 5

[Phil Peterson]

seems to work ok now. Using 2000-01-27-15 on Windows NT.

Comment 6

[sairuh (rarely reading bugmail)]

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...).

Comment 7

[hangas]

This bug seems to have mutated into a key binding bug.  Sending to Chris per his 
suggestion.

Comment 8

[saari (gone)]

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

Comment 9

[saari (gone)]

This bug scares me, raising priority

Comment 10

[Sitsofe Wheeler]

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

Comment 11

[saari (gone)]

Okay PDT people, this bug is driving me nuts so I'm nominating it 

Comment 12

[saari (gone)]

Fixed, thanks Hyatt!

Comment 13

[sairuh (rarely reading bugmail)]

yay! verif w/opt comm bits [2000021808] on linux, mac and winNT.