skip to content

In Selenium, what does the strictFileInteractability capability change for a hidden input type=file?

level: middleimportance: nice to knowfreq 27%

answer

  1. A strictness dial for one element type
  2. Defaults to off
  3. Decides whether hidden file inputs are rejected
  4. Reinstates the keyboard-interactable check
  5. Session capability, not a per-call flag

basics

~20 s

It turns the interactability checks back on for file inputs. Selenium 4 defaults it to false, so a path can be sent to a hidden file input; set it to true and that same element is rejected as not interactable.

solid answer

~40 s

`strictFileInteractability` is a standard W3C capability in Selenium 4, default `false`. Element Send Keys normally scrolls the target into view and waits for it to become keyboard-interactable, but it skips that entire block for an `<input type="file">` unless this capability is `true`. That default is why the everyday upload widget works: a `display: none` or zero-size input behind a styled button accepts an absolute path with no scripted un-hiding. Setting it to `true` reinstates the checks for file inputs, so a hidden one now fails with `element not interactable`. It is a session-wide setting, so turning it on affects every upload in that session - useful when the reachability of the control is itself the subject of the test, expensive when your uploaders legitimately hide their inputs.

code

java · 19 lines
java
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.By;

public class StrictUploadCheck {

  public static void main(String[] args) {
    ChromeOptions options = new ChromeOptions();
    options.setStrictFileInteractability(true);

    ChromeDriver driver = new ChromeDriver(options);
    try {
      driver.get("https://garden-centre.example/plant-finder");
      driver.findElement(By.id("leaf-photo")).sendKeys("/fixtures/fern-leaf.jpg");
    } finally {
      driver.quit();
    }
  }
}

go deeper

for a junior

Recall that a hidden file input still accepts a path by default, so there is no need for a workaround. Knowing the capability exists by name is enough at this level.

for a middle

Explain the mechanism: Element Send Keys skips scroll-into-view and the keyboard-interactable wait for file inputs unless this capability is true, and it defaults to false. Say what error strict mode produces.

for a senior

Show judgment about when the extra strictness earns its keep. Be ready to explain why a suite-wide true breaks styled uploaders, and how a regression that hides the visible trigger stays invisible under the default.

for a principal

Own the policy: which small class of tests genuinely asserts that a control is reachable, and whether that assertion belongs in a browser test at all rather than in an accessibility check. Decide how sessions are partitioned if you adopt it.

## The capability in one line `strictFileInteractability` is a standard W3C WebDriver capability, available in Selenium 4 through `CapabilityType.STRICT_FILE_INTERACTABILITY` and the `setStrictFileInteractability(boolean)` setter on the driver option classes. It is a **boolean whose default is `false`**, and it controls exactly one thing: whether the ordinary interactability checks are applied to an `<input type="file">` when **Element Send Keys** runs against it. ## What the default buys you The Element Send Keys remote end steps first ask whether the target is an `input` in the file upload state. Only when that answer is *no* - **or** when the session's strict file interactability is `true` - does the remote end run the pre-typing block: 1. Scroll the element into view. 2. Start a timer from the session's implicit wait timeout. 3. Wait for the element to become **keyboard-interactable**, or for that timer to fire. 4. Return `element not interactable` if it never becomes interactable. 5. Focus the element if it is not already the active element. With the default `false`, a file input skips that block wholesale. It is never scrolled to, never waited on, and never checked for visibility - the path goes straight into the element's selected files. That is why the pattern every real upload UI uses works out of the box: a `width: 0`, `opacity: 0`, `display: none` or off-screen input sitting behind a styled *Choose a photo* button accepts a path with no scripted un-hiding at all. ## What flipping it to true changes | Setting | File input that is visible | File input that is hidden or off-screen | |---|---|---| | `strictFileInteractability` unset or `false` (default) | the path attaches | the path attaches | | `strictFileInteractability` set to `true` | the path attaches | `element not interactable` | So the capability is really a **strictness dial for one element type**. Turning it on asserts something the default deliberately does not assert: that a real customer could have reached this control with a keyboard. Everything else about the send-keys path is unchanged - the absolute-path rule, the newline separator for a `multiple` input, and the `input` and `change` events all behave the same either way. ## Where it is worth turning on - **You want the accessibility of the control covered by the test.** A permanently `display: none` input that no button ever triggers is a bug for keyboard users, and strict mode is the only WebDriver-level check that notices. - **You are testing the upload control itself**, not merely using it as a step on the way to something else. - **A regression hid the input by accident** - a CSS change that drops the visible trigger leaves the default-mode test green, because the hidden input still accepts the file. ## Where it costs more than it earns - Most upload widgets *legitimately* hide the native input, so a suite-wide `true` turns a normal design into a wall of `element not interactable` failures. - The failure is reported against the input, not against the styled trigger the user actually clicks, so the message points at the wrong element. - Strict mode also brings the implicit wait into play for that element, which slows the negative case down to the full timeout before it reports. - It is a **session capability**, so it applies to every file input in that session; you cannot relax it for one test without starting a different session. ## Reading the behaviour back Because it is a standard capability, the remote end echoes the resolved value in the session's capabilities, so a test can confirm which mode it is running in rather than guessing. The mismatch to watch for is the reverse of the usual one: it is not that a hidden input fails, it is that a hidden input **succeeds** in the default mode - which is correct behaviour that people frequently report as a Selenium bug. ## The practical rule Leave it at the default for suites that use uploads as a step, and reach for `true` only in the small number of cases whose subject genuinely is the upload control's reachability. If you do turn it on, turn it on for a session dedicated to those cases, and expect the styled-uploader tests to need a visible trigger of their own.

  • Why did the specification make skipping the checks the default rather than the exception?
    Because hiding the native input is the normal way to build a styled upload control, and the visible trigger is a label or a button rather than the input itself. If the checks applied by default, almost every real upload would be unautomatable without scripted workarounds, so the specification made the file input the one element type that bypasses them.
  • What error does a hidden file input produce once the capability is true?
    The same one any unreachable element produces: the remote end waits for the element to become keyboard-interactable and, when it does not, returns `element not interactable`. The wait is bounded by the session's implicit wait timeout, so a suite with a long implicit wait pays that full timeout before the failure is reported.
  • Can you enable it for one test and leave it off for the rest?
    Not within one session. It is fixed when the session is created and echoed back in the session capabilities, so switching it means starting a different session with different options. In practice that means grouping the small number of reachability-focused tests so they share a session configured with it turned on.

saying these in an interview costs you the question

  • Claiming Selenium cannot send a path to a hidden file input
  • Believing the capability defaults to true
  • Thinking it controls uploads rather than the interactability check
  • Enabling it suite-wide and then blaming Selenium for the failures
  • Confusing it with a per-call option instead of a session capability