Bits of .NET

🔧 The Enter Key That Worked in One Box and Not the Next

Pressing Enter inside a text input submits the form it belongs to by default – that’s standard browser behavior with no JavaScript required, built around the form having exactly one implicit submit trigger. The moment a form contains more than one button, or a button of type=”button” placed before the real submit button in the markup, or a textarea instead of a single-line input, that default behavior stops being consistent: Enter inside a plain text input still submits, Enter inside a textarea inserts a newline instead (by design), and Enter inside an input sitting near a non-submit button can end up triggering whichever button the browser’s implicit-submission algorithm picks, which isn’t always the one the form’s author assumed.

🔎 The Problem

<form id="search-form">
  <input type="text" name="query" placeholder="Search...">
  <button type="button" onclick="showFilters()">Filters</button>
  <button type="submit">Search</button>
</form>

<!-- Pressing Enter in the text input: submits the form via the
     "Search" button, as expected, because it's the only button
     of type submit.

     Now add a second real submit-capable element, or switch the
     first button's type by accident during a refactor, and the
     browser's implicit submission rules may pick a different
     control than the one the form's author had in mind - with
     no JavaScript error anywhere, because nothing actually broke;
     the form just submitted "correctly" according to a rule
     nobody checked. -->

✅ Fix: Make the Intended Submit Control Explicit, Not Assumed

• Keeping exactly one button of type=”submit” in any form, and giving every other button an explicit type=”button”, removes the ambiguity the browser’s implicit-submission algorithm is resolving, since there’s only ever one candidate left for it to pick.
• For a form that genuinely needs Enter to do something other than the default submit in a specific field (search-as-you-type, a chat message box that should send on Enter but not reload the page), handling the keydown event explicitly and calling preventDefault() on the form’s submit event makes the intended behavior deliberate rather than dependent on markup order.
• Testing Enter-to-submit behavior specifically after any markup reorder, button type change, or added button – not just testing the mouse-click path – catches a change in implicit submission behavior that a purely visual review of the rendered page would never reveal.

⚠️ Why This Slips Past Code Review

• The rendered page looks identical whether a button is type=”button” or missing its type attribute entirely (which defaults to type=”submit” inside a form, a detail that surprises a lot of developers) – the visual difference is nothing, but the keyboard behavior difference is total.
• This is especially common after a refactor that reorders buttons for layout reasons, since the implicit-submission algorithm’s choice can depend on markup order in ways that are specified but rarely memorized, making the resulting behavior change look inexplicable without checking the actual HTML.