In a signup form, pressing Enter in the email field submits the form, and clicking a "Show password" <button> inside it reloads the page. Explain both behaviours and how you would control them.

## Why the button submits The `type` attribute of `<button>` defaults to `submit`. That is deliberate — the element exists primarily to submit forms — but it means every unrelated button placed inside a form is a submit button until you say otherwise: ```html <form action="/signup" method="post"> <input id="pw" name="password" type="password"> <button>Show password</button> <!-- submits! --> <button type="button">Show password</button> <!-- correct --> <button>Create account</button> </form> ``` What looks like a page reload is a real navigation: the form posts to its action, the server responds, and the page you get back happens to look similar. The tell is that anything typed is gone and the network panel shows a document request. The same trap applies to `<input type="submit">` versus `<input type="button">`, and to any "button" built from an anchor or a div — those come with their own, worse problems around focusability and keyboard activation, which is exactly why `<button type="button">` is the right tool. ## Why Enter submits **Implicit submission** is the rule that pressing Enter in a text field submits the form without touching a button. The browser looks for the form's **default button** — the first submit button in tree order — and activates it, exactly as if it had been clicked, which means its `name`/`value` enters the payload and any `formaction` on it applies. If the form has no submit button at all, implicit submission still happens when the form has exactly one field of the kinds that block implicit submission (text-like inputs such as `text`, `search`, `email`, `url`, `tel`, `password`, `number` and the date/time family). That is the rule behind the classic "my one-input search box submits on Enter even though there is no button", and behind its mirror image: add a second text field and Enter stops working, because now nothing tells the browser what the default action is. A `<textarea>` is different — Enter inserts a newline there and does not submit, which is what users expect from a multi-line control. ## Fixing each one correctly **The stray button** is a markup mistake with a markup fix: `type="button"`. Do not fix it with `event.preventDefault()` in a click handler, and do not fix it by removing the button from the form. `preventDefault` in a click handler does suppress the submission, but it leaves the element lying about what it is, so the next person who adds a keyboard shortcut or a second handler reintroduces the bug. Write the type. **Implicit submission** must not be "fixed" by intercepting Enter globally: ```js // Do not do this. form.addEventListener("keydown", (e) => { if (e.key === "Enter") e.preventDefault(); }); ``` That breaks a behaviour keyboard and assistive-technology users rely on, and it is one of the more common accessibility regressions in hand-rolled forms. If Enter is doing the *wrong* thing, the problem is which button is default, not that Enter works: - Order the submit buttons so the safe or primary action is **first in the DOM**, and let the styling layer place it visually wherever the design wants. - Move a destructive action such as Delete into its own form, or give it its own endpoint via `formaction`, so implicit submission cannot reach it. - If a form genuinely must not submit on Enter — a filter panel that applies live, say — the honest answer is usually that it should not be a `<form>` with a submit button in the first place. **If the form should have no submit path at all**, still ask whether users can complete it by keyboard. A form that can only be completed by clicking a specific element is a form some people cannot complete. ## Diagnosing it in the wild The symptom "the page reloads and my input is lost" almost always means an unintended submission. Check three things in order: the `type` of every button inside the form, whether a click handler is running alongside a native submission (two code paths, one user action), and which submit button is first in tree order. Adding a temporary `submit` listener that logs `event.submitter` tells you immediately which element the browser thinks triggered it.