In Cypress, how do you press the Tab key to move focus between fields?

Cypress runs your spec inside the browser, in the same event loop as the application under test. That gives it direct access to the DOM, but it also means a spec cannot manufacture a *real* key press any more than the application can — a script inside the page can only dispatch events that the browser marks as untrusted. `cy.press()` exists to cross that line. ## Two ways to make a key event - **Simulated, in the page.** Cypress's `.type()` and `.trigger()` build DOM events and dispatch them at an element from inside the page. The application's handlers run, but the browser does not treat the event as a real user action and does not apply its own default behaviour. - **Native, through the browser process.** `cy.press()` sends the key out of the page to the Node process that launched the browser, which forwards it to the browser over the protocol it drives the browser with. The browser then dispatches a genuine `keydown` and `keyup` to whatever currently has focus, and applies its own default behaviour — including moving focus on **Tab**. Because focus order is something the browser decides, only the second route can test it. This is why `.type()` has no `{tab}` sequence: Cypress cannot honestly simulate one from inside the page, so it does not pretend to. ## Using it on a real page On a bank statement screen with an account picker, a date-range field and a **Download PDF** button, the keyboard journey looks like this: ```javascript cy.visit('/statements') cy.get('[data-cy=account-select]').focus() cy.press(Cypress.Keyboard.Keys.TAB) cy.get('[data-cy=statement-range]').should('have.focus') cy.press(Cypress.Keyboard.Keys.TAB) cy.get('[data-cy=download-pdf]').should('have.focus') cy.press(Cypress.Keyboard.Keys.ENTER) ``` Three details matter: 1. **Focus something first.** The key goes to the browser window, not to an element you name, so whatever holds focus receives it. Start the journey with an explicit `.focus()` or a `.click()`. 2. **Assert with a new query.** `cy.press()` yields `null`, so `cy.press(...).should('have.focus')` has nothing to assert against. Query the element you expect to be focused and assert there. 3. **Use the constants.** `Cypress.Keyboard.Keys.TAB`, `.ENTER`, `.ESC`, `.HOME`, `.PAGEDOWN` and the arrow keys are exported so your spec does not hard-code a string whose value could change. ## Where the key actually lands There is no element argument, so the key goes wherever focus is — and in Cypress the page under test lives in a frame inside the runner. Before dispatching, Cypress checks whether that frame is the active one and focuses it if it is not, so a key press never leaks into the runner's own UI and never lands on the wrong document. That is also why an explicit `.focus()` or `.click()` at the start of a keyboard journey is worth writing: it makes the starting point of the tab order explicit instead of inheriting whatever the previous command left focused. ## What cy.press() will not do - **No multi-character strings.** `cy.press('a')` is fine; `cy.press('Hello')` is rejected. Long text belongs in `.type()`. - **No modifier combinations.** There is no syntax for Ctrl+C or Shift+Tab; `.type()` owns `{ctrl}c` and `{shift}b`. - **No function keys.** F1 through F12 are unsupported, because they fire browser shortcuts that can derail the rest of the run. - **Not everywhere.** A WebKit-family run has no native-key channel, so `cy.press()` reports that it is not supported in that browser family. - **Not element-targeted.** There is no `.press()` you can chain off `cy.get()`; it is always a parent command on `cy`. ## Choosing between the two commands | Need | Command | Why | |---|---|---| | Type a customer reference into a field | `.type('AC-4471')` | text entry, many characters, in-page is enough | | Move focus with Tab | `cy.press(Cypress.Keyboard.Keys.TAB)` | focus order is the browser's decision | | Activate the focused Download button with Enter | `cy.press(Cypress.Keyboard.Keys.ENTER)` | exercises the browser's default action | | Send Ctrl+C or Shift+Tab | `.type('{ctrl}c')` | `cy.press()` has no modifier syntax | | Fire a handler on a non-focusable element | `.trigger('keydown', { key: 'k' })` | no real key is needed to test a handler | ## One side effect to know about Dispatching native key events puts the page into the browser's **transient activation** state — the same state a real click or key press produces, which browsers require before allowing things like opening a window or starting a capture. If the application under test cancels the default behaviour of `beforeunload`, that activation can make a later navigation away from the page behave differently than it does with simulated events. It is rarely a problem, but it is the one behavioural difference that can surprise you when converting a `.type()` test to `cy.press()`. The rule of thumb is simple: use `.type()` for content, and `cy.press()` when the thing under test is what the **browser** does with a key rather than what your handler does with it.