108787 - Open Web Location doesn't respond to keyboard if there's selected content in its textfield

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[sairuh (rarely reading bugmail)]

found this using 2001.11.06.12-comm bits on linux [rh6.2] and 2001.11.06.08-comm
bits on mac os 10.1. oddly, this is *not* a problem on winNT [2001.11.06.12-comm].

bryner, not sure if you have a bug for this [or if someone else does]...

1. bring up the Open Web Location dialog [File > Open Web Location], and make
sure that there's is content which is selected in its textfield. [you may need
to actually open a url with this dialog, then bring it up again to get to this
state.]
2. try to type, hit Tab, Esc or Enter.

result: nothing happens. you need to mouse-click to activate focus.

not sure if it's limited to this dialog. not a problem with Find. or, perhaps
something funky about having the contents selected in an autocomplete widget?
not sure about that, since the keyboard responds fine after selecting the urlbar...

Comment 1

[sairuh (rarely reading bugmail)]

possible to fix this soon?

Comment 2

[Donnie Cranford]

I am seeing this also on this last 2 weeks on Solaris Sparcbuilds using the
Forte compiler with -O and -xO2 and -xO4 optimizations.

Timeless seems to think this lies in hewitts <dialog/> code

Comment 3

[Joe Hewitt (gone)]

works for me on windows, hinting that this isn't a problem in the XP dialog or
autocomplete code.

Comment 4

[R.K.Aa.]

related: bug 57507, bug 104003, bug 110469

Comment 5

[mozbug1]

I'm having this problem with 0.9.6 on linux.  This is especially a problem
because there is no 'clear' button like there was in netscape 4.7x.  If I want
to paste a url I used to have to open the window, hit the delete key, then paste
with the mouse button.  But now I need to highlight the old text to delete it,
which destroys the clipboard contents.

Even if this bug is fixed I think there should still be a clear button.  Should
I file a seperate RFE?

Comment 6

[Donnie Cranford]

This bug really needs to get some priority, it is apparently affecting all Unix
platforms, I recommend at least getting a 0.9.7 + target

Comment 7

[Brian Ryner (not reading)]

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

Comment 8

[Brian Ryner (not reading)]

Pulling into 0.9.7, this is a fairly severe keyboard navigation problem.

Comment 9

[sairuh (rarely reading bugmail)]

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

Comment 10

[sairuh (rarely reading bugmail)]

could bug 57507 be related?

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

Comment 12

[Boris Zbarsky [:bzbarsky]]

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

Comment 13

[R.K.Aa.]

also related: bug 87946, bug 89106

Comment 14

[Diego Biurrun]

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

Comment 15

[Brian Ryner (not reading)]

On linux, what seems to be happening is that the focused element is set on the
focus controller for the dialog, but we never get an activate event for the
dialog, so keyboard focus never ends up there.  Still investigating.

Comment 16

[Brian Ryner (not reading)]

Ok, patch coming up.  We ned to figure out exactly why the check was added to
only focus the window if the focus controller already has a focused window.

Comment 17

[Brian Ryner (not reading)]

Attachment: patch v1.0

Comment 18

[Brian Ryner (not reading)]

saari, can you give this a spin on mac and see if anything obviously breaks?

Comment 19

[Brian Ryner (not reading)]

Attachment: patch v2.0

This patch makes two changes to how activate events work on GTK:

- NS_ACTIVATE is dispatched when a toplevel receives focus from
HandleMozAreaFocusIn().  This is how it works on win32.  Activate events are no
longer dispatched from SetFocus(), since it will have already been dispatched
if the user gave the window focus, and we don't allow a different toplevel
window to take focus via a call to SetFocus().

- Added GTK to the #ifdef in nsWebShellWindow so that sending the activate
actually does something.

Comment 20

[Brendan Eich [:brendan]]

How's this going?  I'm keen to see it fixed for 0.9.7.

/be

Comment 21

[Christopher Blizzard (:blizzard)]

r/sr=blizzard.  Let's take it for a spin!

Comment 22

[saari (gone)]

Comment on attachment 60913 [details] [diff] [review]
patch v2.0

r=saari

Comment 23

[Brian Ryner (not reading)]

checked in.

Comment 24

[R.K.Aa.]

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

Comment 25

[Diego Biurrun]

Just tried again with 2001121606 - works fine again.  Good work. ---> VERIFIED

Comment 26

[ramune]

Since bug 104003 was marked as a dup of this, I'm reopening the bug as I still
see the behaviour described in 104003's description.  On startup, if the
Navigation toolbar is hidden, Ctrl-Shift-L still doesn't work until I click to
give the display area focus.

CVS pull as of:
checkout start: Sun Dec 16 12:42:55 PST 2001
checkout finish: Sun Dec 16 12:56:51 PST 2001

gcc-2.95.2 Debian/potato Linux 2.4.16, glibc-2.1.3 (against 2.2.19's headers).

Comment 27

[Brian Ryner (not reading)]

That's not at all the same bug.  This bug is about not being able to type once
the open web location dialog appears.  I'm un-duping 104003.

Comment 28

[sairuh (rarely reading bugmail)]

vrfy fixed, using comm bits [2002.01.07.0x] on linux rh7.2.