skip to content

Clicking and Typing

3 roadmaps5 questions

click, sendKeys, clear and submit, plus the interactability rules a click must satisfy. Interviewers probe it because sendKeys appends and clear can leave a controlled field out of sync.

on this pageshow

explore

questions

5

In Selenium, how do you choose between Keys.ENTER, clicking the submit button, and WebElement.submit()?

level: principalimportance: must knowfreq 46%

answer

  1. Three verbs, different amounts of product
  2. Only two match something a person does
  3. One of them is no longer a real endpoint
  4. Script-based, so no actionability work at all
  5. Docs recommend clicking the submission button

basics

~20 s

Click the real control by default, press Enter when the case covers the keyboard journey, and avoid submit. In Selenium 4 submit runs an injected script, so it skips every scroll and interactability check the click command performs.

solid answer

~40 s

Pick the verb that matches the journey the case claims to cover. Clicking the submit button exercises the button's reachability, its enabled state and its handler, and it fails for the right reasons. `sendKeys(..., Keys.ENTER)` exercises whatever the application binds to Enter and is the only option when the search box is not inside a form at all. `WebElement.submit()` is different in kind: in **Selenium 4** it is no longer a WebDriver endpoint, and the client aliases it onto Execute Script, walking up to the nearest form, dispatching a submit event and calling the form's native submit. Because it is a script it does no scrolling, no centre-point work and no interactability check, so it can pass on a form a user could not submit. Selenium's documentation recommends clicking the submission button instead.

code

java · 25 lines
java
import org.openqa.selenium.By;
import org.openqa.selenium.Keys;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;

public class KbSearchSubmit {
  public static void main(String[] args) {
    WebDriver driver = new ChromeDriver();
    try {
      driver.get("https://helpdesk.example.com/kb");
      WebElement search = driver.findElement(By.id("kb-search"));
      search.clear();
      search.sendKeys("printer jam");

      // Keyboard journey: press the key a person presses.
      search.sendKeys(Keys.ENTER);

      // Mouse journey: exercise the control itself.
      driver.findElement(By.id("kb-search-button")).click();
    } finally {
      driver.quit();
    }
  }
}

go deeper

for a junior

Recall that there is more than one way to submit, and that clicking the actual button is the safe default. Know that Enter is sent as part of a sendKeys call rather than as its own command.

for a middle

Explain what each verb dispatches: Enter goes through the key input source on the focused field, the button click goes through the full Element Click contract, and submit is executed as a script.

for a senior

Show the diagnostic value. Explain why a suite built on submit can stay green while the submit button is broken, and why an element outside any form makes submit throw outright.

for a principal

Own the convention across the suite. Decide which verb each surface uses, tie it to the journey the case claims to cover, treat submit as a review finding, and put the chosen verb behind one shared step so it can be changed in a single place.

## Three verbs that look interchangeable and are not A helpdesk knowledge-base search box can be driven three ways in Selenium, and the choice is a design decision rather than a matter of taste: - `search.sendKeys("printer jam", Keys.ENTER)` - press the key a keyboard user presses. - `driver.findElement(By.id("kb-search-button")).click()` - press the button a mouse user presses. - `search.submit()` - ask Selenium to submit the enclosing form. They exercise different amounts of the product, and only two of them correspond to something a person can do. ## What `submit()` actually is in Selenium 4 This is the fact the question turns on. In **Selenium 4** `submit()` is no longer backed by its own WebDriver endpoint. The Java client's W3C command codec aliases the `SUBMIT_ELEMENT` command onto **Execute Script** and sends a short script that: 1. Walks up from the element until it reaches a `FORM` node or runs out of parents. 2. Builds a `submit` event and dispatches it on that form. 3. If the event was not cancelled, calls `HTMLFormElement.prototype.submit` on the form. If no form is found, the script throws, `RemoteWebElement.submit()` catches the resulting `JavascriptException`, and rethrows `UnsupportedOperationException` with the message *"To submit an element, it must be nested inside a form element"*. Selenium's own documentation states the position plainly: because it now functions by executing a script, it is recommended not to use this method and to click the applicable form submission button instead. The operational consequence is larger than the implementation detail. Because it is a script rather than a pointer command, `submit()` performs **none** of the Element Click preparation: no scroll into view, no in-view centre point, no check that anything is interactable. It will happily submit a form the user could not have submitted - one behind a modal, one whose submit button is disabled, one scrolled far off screen. | Verb | What it exercises | What it skips | Honest use | |---|---|---|---| | `sendKeys(..., Keys.ENTER)` | Whatever the app binds to Enter on the focused field | The button, its state and its handler | The keyboard journey; a search box outside any form | | Clicking the button | The button's own reachability, state and handler | Any keyboard-only submission path | The mouse journey, and the default for most cases | | `submit()` | The form's submit path only | Scrolling, interactability, the button entirely | Effectively none in Selenium 4 | ## How to decide 1. **Name the journey the test claims to cover.** A case titled "search from the keyboard" should press Enter; a case about the search button should click the button. If the title does not imply a journey, the test is asserting a result, and the cheapest reliable verb wins. 2. **Prefer the verb that can fail for the right reason.** Clicking the button fails when the button is unreachable or disabled - which is usually a real defect. `submit()` cannot fail that way, so it converts a class of real defects into green runs. 3. **Check the markup before you assume a form exists.** Many knowledge-base search boxes are a plain `input` in a `div` with a key handler and no `form` at all. Enter works, the button works, `submit()` throws `UnsupportedOperationException`. 4. **Pick one convention per surface and write it down.** The cost of mixing verbs across a suite is not the verbs; it is that no reviewer can tell which journeys are actually covered. ## The trade-offs worth saying out loud - Enter is closest to how people use a search box, and it is the only one of the three that works when there is no form and no visible button. - Enter can also pass while the button is broken, so a suite that only ever presses Enter has no coverage of the control most users click. - Clicking the button carries the click command's whole contract - centre point, paint tree, scroll - and that contract is the point: it is the part of the product you want under test. - `submit()` is the fastest and the least informative. In Selenium 4 there is essentially no scenario where it is the right answer, and a suite still using it is usually one that adopted it before the behaviour changed. ## What a lead should actually enforce - Default to clicking the real control; reserve Enter for cases that specifically cover the keyboard path, and say so in the case name. - Treat `submit()` in a review as a finding, with the reason attached: it is a script, it skips every actionability guarantee, and it will pass on forms a user cannot submit. - Where the same search surface is driven from dozens of cases, put the chosen verb behind one shared step so changing the convention is a single edit, not an archaeology exercise.

  • What happens when you call submit() on an element that is not inside a form?
    The injected script walks up the tree, finds no form, and throws. `RemoteWebElement.submit()` catches the `JavascriptException` and rethrows `UnsupportedOperationException` with the message that an element must be nested inside a form element to be submitted. Many modern search boxes are exactly this shape - an input in a div with a key handler.
  • Why can submit() pass on a form that a real user could not submit?
    Because it is executed as a script rather than dispatched as a pointer command, it performs none of the Element Click preparation: it does not scroll the element into view, does not compute an in-view centre point, and does not check that anything is interactable. A disabled button, an overlay or an off-screen form does not stop it.
  • What does a suite lose if every search case presses Enter and none clicks the button?
    Coverage of the control most users actually click. Enter exercises the application's key binding and nothing about the button's reachability, enabled state or handler, so the button can break without a single failing case. Name the journey in the case title so reviewers can see which path is covered.

saying these in an interview costs you the question

  • Treats submit as a faster equivalent of clicking the button
  • Assumes submit still has its own WebDriver endpoint
  • Thinks submit performs the same actionability checks as click
  • Believes every search box lives inside a form element
  • Mixes Enter and button clicks with no stated convention
open as a page

In Selenium, what scrolling does WebElement.click() perform before clicking, and when does it skip it?

level: middleimportance: should knowfreq 52%

basics

~20 s

It calls scrollIntoView with instant behaviour, block end and inline nearest, so the bottom of the element is aligned with the bottom of the viewport. It skips the scroll when the element is already in view.

open as a page

In Selenium, why does WebElement.sendKeys append rather than replace an input's existing value?

level: middleimportance: should knowfreq 66%

basics

~20 s

Send Keys never resets the field. When the input is not already focused the driver focuses it and puts the caret after the existing text, then types character by character, so the new characters land on the end.

open as a page

In Selenium, why can clear() empty a framework-controlled input yet leave the app using the old text?

level: seniorimportance: should knowfreq 47%

basics

~20 s

Clear resets the value through the HTML clear algorithm and dispatches no key events at all. A component that keeps its own copy of the field's value and updates it from typing can miss the reset, so its copy stays stale.

open as a page

In Selenium, where on an element does WebElement.click() actually land, and how is that point computed?

level: seniorimportance: should knowfreq 41%

basics

~10 s

Selenium clicks the in-view centre point: the centre of the intersection between the element's first client rectangle and the viewport, floored to whole pixels. Whatever is painted at that one coordinate receives the click.

open as a page