Bug 24304 – REGRESSION (r39864): Hitting the space bar to select an <input type=radio> or push an <input type=button> causes the page to scroll down.

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

[Marc-André Decoste]

This bug was introduced by http://trac.webkit.org/changeset/39864.

The following form helps expose the problem which occurs when you set the focus to the radio button and hit the space bar on your keyboard. The page scrolls... and it shouldn't... right?

<form action="http://www.example.com/" method="post">
<input type="text" name="one" />
<input type="radio" name="two" />
<div style="height:5000px;"> </div>
<input type="submit" />
</form>

[Darin Adler]

I tested this on Mac and could not reproduce the problem. Space bar worked fine and did not cause any scrolling. Maybe it's only for non-Mac platforms.

The reason this should not happen is that the code in the radio button implementation should call setDefaultHandled(true) and that should cause the scrolling code to not do anything.

[Marc-André Decoste]

That was my guess (the radio button to call setDefaultHandled(true)), but I couldn't find where that code should be... I'm willing to fix it if I can find where it is :-)...

[Marc-André Decoste]

Actually, I thought it could be there, but a comment says it shouldn't... for some reason...

WebKit\WebCore\html\HTMLInputElement.cpp
HTMLInputElement::defaultEventHandler()
[...]
  case RADIO:
    setActive(true, true);
    // No setDefaultHandled() - IE dispatches a keypress in this case.
    return;

This code was added as part of:
http://trac.webkit.org/changeset/28620

[Alexey Proskuryakov]

If we were to call setDefaultHandled(true) in keydown event handler, then keypress wouldn't be dispatched, not matching IE.

[Francois Botha]

Similar thing happens with I use the space bar to press a button.  Does this warrant a separate issue to be filed?

[Darin Adler]

I think it would be fine to have one bug that covers both.

[Alexey Proskuryakov]

<rdar://problem/6674180>

[Adele Peterson]

Created attachment 28672 [details]
initial version of patch

[Adele Peterson]

Darin came up with an initial patch (see attached).  We were calling the base class early in too many cases.

[Darin Adler]

Adele and I figured out that the real problem here is that HTMLInputElement goes out of its way to give the default event handler a crack at the event before it handles the event. For <input type="text"> that's OK, but not for other input types. This will be easy to fix.

[Darin Adler]

Testing the patch on the Mac now to make sure it doesn’t cause any behavior regressions. If not, I’ll put it up for review.

[Darin Adler]

http://trac.webkit.org/changeset/41781

Contrary to what the title said, this did *not* affect <button>. If there are problems with <button> elements those are a separate bug.