903925 - Using keyboard to select value in <select> for Product/Component with enter key ends up submitting form on IE and Chrome for Windows

Status: NEW

(Bugzilla :: User Interface, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

This is spinning out from bug 903715.

See the comments in the bug for the detail:

(In reply to Vacation until Aug 19.  Do not ask for review. from comment #0)
> Byron, I finally hunted this down and it's a change in the browser, not
> bugzilla; the cache bits were just red herrings.
> 
> BUILD: Any build since bug 501496 was checked in.
> 
> STEPS TO REPRODUCE:
> 
> 1)  Load this bug.
> 2)  Click on the "Product" dropdown
> 3)  Type "F" so that "Finance" is selected
> 4)  Hit enter
> 
> EXPECTED RESULTS: Select dropdown closes, "Finance" is still selected there,
> focus is transferred to the assignee field which has its contents selected.
> 
> ACTUAL RESULTS: As expected results, but then the form submits and I'm asked
> to pick a correct component.
> 
> At a guess, the enter press ends up somehow being also processed on the text
> input, which triggers a form submission...
> 
> Be careful to test this with the Product <select>.  If you do it with the
> Component one, you'll end up actually switching components a lot.

(In reply to Vacation until Aug 19.  Do not ask for review. from comment #8)
> WebKit, Blink, Presto do not submit the form in this case when I close the
> dropdown via enter.

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) (offline: 8/13-8/18 JST) from comment #10)
> (In reply to Vacation until Aug 19.  Do not ask for review. from comment #8)
> > WebKit, Blink, Presto do not submit the form in this case when I close the
> > dropdown via enter.
> 
> No, IE 11 and Google Chrome (for Win) submit the form! Presto doesn't so,
> though.
> 
> I think this is a bug of bugzilla if it's not intentional behavior.
> 
> bugzilla calls preventDefault of change event. However, it's not
> cancellable. I have no idea for smart fix of this bug even on bugzilla side.

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) (offline: 8/13-8/18 JST) from comment #12)
> Okay, I confirmed that as bz mentioned, Google Chrome for Mac and Safari
> don't submit the form because they prevent keypress event on Mac.
> 
> So, Blink behaves differently on Windows and Mac.
> 
> There are two issues:
> 
> 1. Should we prevent to fire keypress event when Enter key pressed when
> dropdown is opened?
> 2. Anyway, bugzilla needs to change the code if it's not intentional
> behavior.
> 
> For compatibility with IE, I prefer to keep current behavior. And I hate to
> change our behavior only on Mac.

This bug happens with:

* Gecko 25 or later (due to bug 501496)
* IE 11
* Google Chrome for Windows

This bug doesn't happen with:

* Gecko 24 or earlier
* Safari
* Google Chrome for Mac
* Opera (Presto) for Win/Mac

The difference of them is whether Enter keypress event is fired on assignee <input> element after dropdown of <select> element is closed by Enter key.

You can confirm the behavior on each browser with attachment 788748 [details].

Comment 1

[Frédéric Buclin]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) (offline: 8/13-8/18 JST) from comment #0)
> > bugzilla calls preventDefault of change event. However, it's not
> > cancellable. I have no idea for smart fix of this bug even on bugzilla side.

> > 2. Anyway, bugzilla needs to change the code if it's not intentional
> > behavior.

Bugzilla needs to change which code? And what changed in this preventDefault method?

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Frédéric Buclin from comment #1)
> And what changed in this preventDefault method?

Bug 501496 changes keydown and keypress relation. Fx24 or earlier, keypress event is fired even if precede keydown event is consumed (its preventDefault() is called). But at that time, keypress event's defaultPrevented is set true.

Now, keypress event is never fired if its precede keydown event is consumed. This is right behavior for DOM Level 3 Events and same behavior with other browsers.

At this change, <select> element became to handle Enter key at keydown event instead of keypress event. Therefore, the event order was changed as:

Before: keydown -> keypress -> change
After:  keydown -> change -> keypress

Bugzilla handles the change event of <select> for Product or Compoenent and moves focus to assignee's <input> element.

Therefore, in this bug, Enter keypress event is fired on the assignee's <input> element which causes submitting the form.

> Bugzilla needs to change which code?

So, it's difficult issue. Bugzilla handles "change" event of the <select> element. The event is not cancellable. Bugzilla needs to call preventDefault() of the keydown which caused the change event. Or, ignores keypress event fired immediately after the focus move.

The latter is ugly approach. But I'm not sure that the former approach is possible on the other browsers (IE and Chrome for Windows).

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

It might fix this bug always to call peventDefault() of Enter keydown event. IIRC, even if preventDefault() is called, it doesn't prevent the default action for the Enter keydown event on <select> on all browsers.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

This isn't reproduced with Gecko 26 or later because of the fix of bug 903715. I'll request approval for 25 too.

However, this should be left open for other browsers (except deciding WONTFIX).