76814 - esc/enter won't dismiss dialogs which don't have initial focus

Status: RESOLVED DUPLICATE of bug 58853

(Core :: XUL, defect)

Description

[sairuh (rarely reading bugmail)]

in dialogs which don't have initial focus set [ie, no widget in focus] --such as
Preferences, Mailnews Account Settings and Form Data Manager-- hitting the
Escape or Return key will not dismiss them. you need to click on some widget for
it to work. i had originally seen this on mac and linux comm opt bits
2001.04.19.08 [this is not a problem on win32], but spoke with saari who said
that the fix to bug 76746 might take care of the problem.

alas with my 7:15pm linux debug build, this problem persists.

Comment 1

[sairuh (rarely reading bugmail)]

this is a regression --as hitting esc/enter dismissed such dialogs in previous
builds.

nominating for mozilla0.9.

Comment 2

[sairuh (rarely reading bugmail)]

would this be a dup of bug 76450?

Comment 3

[David Hyatt]

Nope, this one is its own bug.

Comment 4

[sairuh (rarely reading bugmail)]

cc'ing sujay: this also affects the Customize Sidebar dialog.

Comment 5

[Keyser Sose]

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

Comment 6

[Peter Trudelle]

->danm

Comment 7

[Peter Trudelle]

->0.9.3, limbo candidate.

Comment 8

[sairuh (rarely reading bugmail)]

another instance of this: the About Mozilla dialog [ie, only when you set About
Mozilla to be a modal dialog in debug prefs].

Comment 9

[Dan M]

  This is caused by the lack of initial focus on any widget in dialogs on Linux 
and Mac platforms. In Windows dialogs, a keystroke is dispatched to the correct 
subwidget, from where it bubbles out until it finds a parent widget that will 
handle it. Mac (and I assume Linux; both misbehave in apparently the same way) 
dialogs send the keystroke directly to the top-level window, bypassing all 
widgetry, where it is ignored. As noted above, a mouse click will set a focused 
widget where there was none before, and then the event can be dispatched 
correctly.
  I could try to make windows pass key events they receive into their widget 
hierarchy, but I think it would be more proper to get the focus correct in the 
first place. That makes this bug a duplicate of bug 58853 (or maybe bug 49811).


*** This bug has been marked as a duplicate of 58853 ***