16339 - <Enter> in html:textarea = button click instead of carriage return

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect, P3)

Description

[esther]

Using 19991013m11 build on Mac PPC only, pressing <Return> while in the Notes
editing box of the Options tab of a New Card is a button click instead of a
carriage return.

1. Launch Address book
2. Select Personal Addres Book
3. Select a Card and double-click or Click New Card
4. Select the Options tab
5. Get focus in Notes area and start tying a few characters then press <Return>

Result:  the Card closes
Expected: the cursor to move to the next line so user can type in more
information

Comment 1

[hangas]

Mass move to M13.

Comment 2

[Phil Peterson]

Happens on Windows too.

Comment 3

[Richard Zach]

Also happens on Linux 2000.01.23.09. Marking all platforms, remove PP.

Comment 4

[hangas]

Chris, Steve: who should own this bug?

Comment 5

[saari (gone)]

Is this the OK button listener doing its thing?

I don't know who should own this, probably not me :-)

Comment 6

[hangas]

This is really a bug in html:textarea not in the address book.  Changing 
component.  The bug can be demonstated in the notes field of the New Address Book 
Card dialog.

Comment 7

[Brendan Eich [:brendan]]

Hangas, why did you assign this bug to me?  Prolly because it got passed from 
saari already.

Giving to a textarea owner who might know how to handle key binding problems.

/be

Comment 8

[buster]

removed "mac only" from subject according to phil and [e-mail].

paul, I'm not convinced it's a bug in the textarea.  textarea's in other dialogs 
and in HTML content seem to work fine on all platforms, so there's something 
specific about the New Card dialog that's wacky (not wrong, necessarily, just 
different from everywhere else.)  Could you possibly narrow it down to an 
independent test case of some sort?

It sounds to me like the enter key is getting somewhere inappropriately, maybe 
the OK button listener as Chris suggested. If I had a reasonable little test 
case, I could probably track it down much more quickly.

In case somebody can get to this before me, what I would do is set a breakpoint 
in nsEnderEventListener::KeyPress() and see if the text control ever sees the 
enter key at all.  If it is, I might trace into the various propogation calls to 
see who is grabbing it, if it wasn't obvious from the test case.

Comment 9

[hangas]

Brendan: I did not enter you name, just the component - it went to you 
automatically.
Buster: This dialog does have (dialogOverlay.xul) :
<key keycode="VK_ENTER" oncommand="doOKButton()"/>
<key keycode="VK_RETURN" oncommand="doOKButton()"/>
<key keycode="VK_ESCAPE" oncommand="doCancelButton()"/>
but we need this in the dialogs.  In fact this particular dialog has other text 
fields that need to activate the OK button for ENTER and RETURN, but not in 
textareas. In text area RETURN should just go to the next line, on the Mac ENTER 
should still activate OK.

Comment 10

[hangas]

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

Comment 11

[buster]

assigning to hyatt based on this email from hyatt:

The problem is that the key bindings event listener is a capturer, and it should 
be a bubbler instead.  I believe we should make this change
in M14 and see what breaks.  Right now, because key bindings are capturers, they 
steal all events, and they shouldn't be doing that. 

I also think that XBL should be used to define the Enter/Esc dialog bindings 
rather than XUL key bindings, but that requires more work
(that I have scheduled for M14) to be done first. 

The immediate fix IMO is to make the XUL key listener NOT be a capturer. 

Comment 12

[David Hyatt]

Mmm, thinking about this more.  Making the key listener a bubbler won't even fix 
this, since it's right and proper for you to bubble up an enter press.  We're 
actually going to have to have to just hack this to know that certain focused 
widgets don't cause dialogs to close.

Comment 13

[hangas]

Hack it where?  There is no way for the dialog to know about the overlay that 
contains these key bindings or the overlay to know that the dialog has these 
widgets.

Comment 14

[David Hyatt]

Fixed.

Comment 15

[David Hyatt]

Fixed.

Comment 16

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/74dfc4c33614
[fenix] For https://github.com/mozilla-mobile/fenix/issues/16339 - Initialize FxaAccountManager with also a CrashReporter (https://github.com/mozilla-mobile/fenix/pull/16340)