Form Input Validation With the Scrapeless Scraping Browser

TL;DR:

• Assigning element.value directly fires no events at all. In a measured run, direct assignment produced an empty event list while locator.fill() produced focus, beforeinput, and input — the value lands in the DOM either way, so the failure is silent.
• Direct assignment still satisfies HTML5 constraint validation and still populates FormData. Setting value is not rejected by the browser; it is simply unobserved, and what breaks is any page logic that reacts to events.
• The fields that actually break are the ones other fields depend on. Setting a <select>'s value directly left the dependent input hidden and the submit button disabled, while selectOption() revealed both.
• JavaScript date pickers can discard what you typed. On one public date field, filling then pressing Escape or clicking away returned the field to an empty string; committing with Enter produced the widget's own normalized format.
• setInputFiles() works even though the browser is not on your machine. Playwright streams the local file to the remote session, and the upload appears in the submitted form data.
• Validation errors are readable without screenshots. validity, validationMessage, and a blocked requestSubmit() expose exactly which constraint failed and why.
• Free to start. New Scrapeless accounts include free Scraping Browser runtime — sign up at app.scrapeless.com.

Why a filled field can still be an empty form

A form field can hold the right text and still submit nothing useful. The value is in the DOM, a screenshot looks correct, and the page behaves as though the field was never touched — the next field never appears, the submit button stays disabled, or a validation message the page renders itself never clears.

The cause is not the value. It is the events that were never dispatched alongside it. Modern forms rarely read raw DOM values at submit time; they subscribe to input and change, keep their own copy of the state, and drive everything else from that copy. Write to .value and you update the DOM while leaving every subscriber unaware.

This guide measures that behavior rather than asserting it, then works through the widget classes where the gap actually shows up: dependent selects, JavaScript date pickers, file inputs, and forms whose constraints reject the submission outright. Everything below runs on Playwright connected to Scrapeless Scraping Browser, a customizable, anti-detection cloud browser powered by self-developed Chromium. If you need the fill-and-submit fundamentals first, the Puppeteer form submission guide covers that ground.

Prerequisites

• Node.js 18 or newer
• A Scrapeless account and API key — sign up at app.scrapeless.com
• Working knowledge of CSS selectors and the DOM event model

Install

The browser is remote, so playwright-core is all you need — no bundled Chromium download:

pnpm add playwright-core@1.56.1

Set your API key from the environment rather than putting it in source:

export SCRAPELESS_API_KEY="paste-your-key-here"

Configure: connect Playwright to the cloud browser

Scraping Browser speaks the Chrome DevTools Protocol, so connectOverCDP is the entry point. The public test form below belongs to the Selenium project and exists specifically for automation practice:

import { chromium } from 'playwright-core';

const endpoint = 'wss://browser.scrapeless.com/api/v2/browser?' + new URLSearchParams({
  token: process.env.SCRAPELESS_API_KEY,
  sessionTTL: '300',
});

const browser = await chromium.connectOverCDP(endpoint);
const context = browser.contexts()[0];
const page = context.pages()[0] || await context.newPage();

await page.goto('https://www.selenium.dev/selenium/web/web-form.html', {
  waitUntil: 'domcontentloaded',
});

console.log('chromium:', browser.version());
console.log('title:', await page.title());
console.log('form method:', await page.getAttribute('form', 'method'));
await browser.close();

chromium: 140.0.7339.35
title: Web form
form method: get

One note specific to remote sessions: the default page enforces Trusted Types, so page.setContent() is rejected before it can write markup. Navigating to a data: URL is the working alternative, and the measurement below uses exactly that.

Basic implementation: measure what each technique emits

Instead of trusting a rule of thumb, instrument the input. This fixture records every event that reaches the field, and also renders its own validation message from an input listener — the pattern that makes silent failures visible:

import { chromium } from 'playwright-core';

const endpoint = 'wss://browser.scrapeless.com/api/v2/browser?' + new URLSearchParams({
  token: process.env.SCRAPELESS_API_KEY,
  sessionTTL: '300',
});
const browser = await chromium.connectOverCDP(endpoint);
const context = browser.contexts()[0];
const page = context.pages()[0] || await context.newPage();

const fixture = `<!doctype html><meta charset=utf-8><title>fixture</title>
<form id=f>
  <input id=t name=t type=text required minlength=4>
  <output id=err></output>
</form>
<script>
window.__ev = [];
var el = document.getElementById('t');
['focus','beforeinput','input','change','keydown','keyup'].forEach(function(type){
  el.addEventListener(type, function(){ window.__ev.push(type); });
});
el.addEventListener('input', function(){
  document.getElementById('err').textContent = el.validity.valid ? 'ok' : 'too short';
});
</script>`;
const fixtureUrl = 'data:text/html;charset=utf-8,' + encodeURIComponent(fixture);

async function trial(name, action) {
  await page.goto(fixtureUrl, { waitUntil: 'load' });
  await action();
  await page.waitForTimeout(200);
  const state = await page.evaluate(() => ({
    events: window.__ev.slice(),
    formData: new FormData(document.getElementById('f')).get('t'),
    valid: document.getElementById('t').validity.valid,
    errorUi: document.getElementById('err').textContent,
  }));
  console.log(name);
  console.log('  events  :', JSON.stringify(state.events));
  console.log('  formData:', JSON.stringify(state.formData), '| valid:', state.valid);
  console.log('  error-UI:', JSON.stringify(state.errorUi));
}

await trial('A: el.value = "hello"', () =>
  page.$eval('#t', el => { el.value = 'hello'; }));

await trial('B: el.value + dispatchEvent(input)', () =>
  page.$eval('#t', el => {
    el.value = 'hello';
    el.dispatchEvent(new Event('input', { bubbles: true }));
  }));

await trial('C: locator.fill("hello")', () => page.fill('#t', 'hello'));

await trial('D: locator.pressSequentially("hello")', () =>
  page.locator('#t').pressSequentially('hello'));

await browser.close();

A: el.value = "hello"
  events  : []
  formData: "hello" | valid: true
  error-UI: ""
B: el.value + dispatchEvent(input)
  events  : ["input"]
  formData: "hello" | valid: true
  error-UI: "ok"
C: locator.fill("hello")
  events  : ["focus","beforeinput","input"]
  formData: "hello" | valid: true
  error-UI: "ok"
D: locator.pressSequentially("hello")
  events  : ["focus","keydown","beforeinput","input","keyup","keydown","beforeinput","input","keyup","keydown","beforeinput","input","keyup","keydown","beforeinput","input","keyup","keydown","beforeinput","input","keyup"]
  formData: "hello" | valid: true
  error-UI: "ok"

Read the first case carefully. Direct assignment produced an empty event list, and yet FormData carried "hello" and the field reported itself valid. The value is genuinely there. What never happened is the page's own reaction: the error output stayed empty because nothing told it to update.

That result reframes the usual advice. Setting .value is not inherently broken — it is invisible. A plain HTML form with no scripting submits it correctly. A form whose behavior is wired to events treats the field as untouched, and the symptom appears somewhere else entirely.

fill() produces the compact sequence most pages need: focus, then beforeinput, then input. pressSequentially() produces the full per-character keyboard sequence, which matters only when the page inspects individual keystrokes, such as an autocomplete that queries on every letter. The W3C UI Events specification defines the ordering these techniques imitate, and the WHATWG DOM Standard defines how a manually dispatched event propagates — including the isTrusted flag that separates it from a real user action.

Get your API key on the free plan: app.scrapeless.com

Advanced patterns: the widgets that need more than a value

Selects that unlock other fields

This is where direct assignment stops being merely invisible and starts costing you data. The fixture below reveals a second field and enables the submit button from the select's change handler:

import { chromium } from 'playwright-core';

const endpoint = 'wss://browser.scrapeless.com/api/v2/browser?' + new URLSearchParams({
  token: process.env.SCRAPELESS_API_KEY,
  sessionTTL: '300',
});
const browser = await chromium.connectOverCDP(endpoint);
const context = browser.contexts()[0];
const page = context.pages()[0] || await context.newPage();

const fixture = `<!doctype html><meta charset=utf-8><title>conditional</title>
<form id=f>
  <select id=plan name=plan>
    <option value="">choose</option>
    <option value="basic">Basic</option>
    <option value="team">Team</option>
  </select>
  <div id=extra hidden><input id=seats name=seats type=number></div>
  <button id=go type=submit disabled>Continue</button>
</form>
<script>
var plan = document.getElementById('plan');
plan.addEventListener('change', function(){
  document.getElementById('extra').hidden = (plan.value !== 'team');
  document.getElementById('go').disabled = !plan.value;
});
</script>`;
const url = 'data:text/html;charset=utf-8,' + encodeURIComponent(fixture);

async function trial(name, action) {
  await page.goto(url, { waitUntil: 'load' });
  await action();
  await page.waitForTimeout(200);
  console.log(name, '->', JSON.stringify(await page.evaluate(() => ({
    selectValue: document.getElementById('plan').value,
    seatsVisible: !document.getElementById('extra').hidden,
    submitEnabled: !document.getElementById('go').disabled,
  }))));
}

await trial('A: select.value = "team"', () =>
  page.$eval('#plan', el => { el.value = 'team'; }));

await trial('B: select.value + dispatchEvent(change)', () =>
  page.$eval('#plan', el => {
    el.value = 'team';
    el.dispatchEvent(new Event('change', { bubbles: true }));
  }));

await trial('C: locator.selectOption("team")', async () => {
  await page.selectOption('#plan', 'team');
  await page.waitForSelector('#seats', { state: 'visible' });
  await page.fill('#seats', '25');
});

await browser.close();

A: select.value = "team" -> {"selectValue":"team","seatsVisible":false,"submitEnabled":false}
B: select.value + dispatchEvent(change) -> {"selectValue":"team","seatsVisible":true,"submitEnabled":true}
C: locator.selectOption("team") -> {"selectValue":"team","seatsVisible":true,"submitEnabled":true}

Case A is the failure worth remembering. The select genuinely holds "team", so a script that verifies its own work by reading the value back reports success — while the seats field it was supposed to fill is still hidden and the button it was supposed to click is still disabled. selectOption() avoids the whole class of problem because it dispatches input and change the way a user selection does.

Checkboxes and radios

Use check() and uncheck() rather than click(). They assert the resulting state instead of toggling blindly, so a box that already carries checked in the markup does not get flipped the wrong way:

await page.check('#my-check-2');
await page.uncheck('#my-check-1');
await page.check('#my-radio-2');

Date pickers that discard what you typed

A field that looks like a date input is often a text input with a JavaScript calendar attached, and the calendar owns the value. Six ways of entering the same date into one public date field produced four different stored values:

Three of those are traps. Dismissing the overlay with Escape or by clicking elsewhere returned the field to an empty string, because the widget treats the dismissal as an abandoned edit. Typing character by character let the calendar reformat the field mid-entry and produced a value that matches nothing. Direct assignment kept the literal text only because the widget never engaged at all — which means the calendar's internal state and the field disagree.

Committing with Enter is the ending that works, and the widget rewrites the value into its own display format. Verify the committed value rather than assuming your input survived:

await page.fill('input[name="my-date"]', '2026-08-06');
await page.press('input[name="my-date"]', 'Enter');
console.log(await page.inputValue('input[name="my-date"]'));
// 08/06/2026

Where a true <input type="date"> is used instead, the picture is simpler: the value must be an ISO YYYY-MM-DD string regardless of the format shown to the user.

File inputs on a browser that is not local

A reasonable worry with a cloud browser is that file uploads cannot work, since the file lives on your machine and the browser does not. setInputFiles() handles the transfer over the protocol, so no operating-system dialog is ever involved:

import fs from 'node:fs';
import { chromium } from 'playwright-core';

fs.writeFileSync('upload-sample.txt', 'scrapeless form upload fixture\n');

const endpoint = 'wss://browser.scrapeless.com/api/v2/browser?' + new URLSearchParams({
  token: process.env.SCRAPELESS_API_KEY,
  sessionTTL: '300',
});
const browser = await chromium.connectOverCDP(endpoint);
const context = browser.contexts()[0];
const page = context.pages()[0] || await context.newPage();

await page.goto('https://www.selenium.dev/selenium/web/web-form.html', {
  waitUntil: 'domcontentloaded',
});

await page.setInputFiles('input[name="my-file"]', './upload-sample.txt');

console.log(await page.$eval('input[name="my-file"]', el => ({
  files: el.files.length,
  name: el.files[0].name,
  hasBytes: el.files[0].size > 0,
})));

await Promise.all([
  page.waitForNavigation({ waitUntil: 'domcontentloaded' }),
  page.click('button[type="submit"]'),
]);
console.log('submitted my-file:',
  JSON.stringify(new URL(page.url()).searchParams.get('my-file')));
await browser.close();

{ files: 1, name: 'upload-sample.txt', hasBytes: true }
submitted my-file: "upload-sample.txt"

The remote session received the file, the FileList is populated, and the filename appears in the submitted form data.

Multi-step forms

Treat each step as a precondition rather than a delay. After committing the field that advances the form, wait for a control that only exists on the next step before touching it:

await page.selectOption('#plan', 'team');
await page.waitForSelector('#seats', { state: 'visible' });
await page.fill('#seats', '25');

Waiting on the element itself keeps the script tied to the form's real state, which is the same principle that makes the conditional-select case work.

Read the submitted state back

The only authoritative confirmation is what the server received. This form submits by GET, so the accepted values land in the query string of the next page:

import { chromium } from 'playwright-core';

const endpoint = 'wss://browser.scrapeless.com/api/v2/browser?' + new URLSearchParams({
  token: process.env.SCRAPELESS_API_KEY,
  sessionTTL: '300',
});
const browser = await chromium.connectOverCDP(endpoint);
const context = browser.contexts()[0];
const page = context.pages()[0] || await context.newPage();

await page.goto('https://www.selenium.dev/selenium/web/web-form.html', {
  waitUntil: 'domcontentloaded',
});

await page.fill('#my-text-id', 'Ada Lovelace');
await page.selectOption('select[name="my-select"]', '2');
await page.check('#my-check-2');
await page.uncheck('#my-check-1');
await page.check('#my-radio-2');
await page.fill('input[name="my-date"]', '2026-08-06');
await page.press('input[name="my-date"]', 'Enter');

await Promise.all([
  page.waitForNavigation({ waitUntil: 'domcontentloaded' }),
  page.click('button[type="submit"]'),
]);

const params = Object.fromEntries(new URL(page.url()).searchParams.entries());
for (const key of ['my-text', 'my-select', 'my-check', 'my-date']) {
  console.log(key.padEnd(10), JSON.stringify(params[key]));
}
await browser.close();

my-text    "Ada Lovelace"
my-select  "2"
my-check   "on"
my-date    "08/06/2026"

Checking the server's view tells you the form was accepted, not merely that the fields were populated. Note that my-date carries the widget's committed format, not the string that was typed.

Reading validation errors out of the DOM

When a submission is rejected, the browser already holds a structured explanation. The constraint validation API in the HTML Standard exposes which rule failed and the message the browser would display, so there is no need to screenshot the page and read pixels:

import { chromium } from 'playwright-core';

const endpoint = 'wss://browser.scrapeless.com/api/v2/browser?' + new URLSearchParams({
  token: process.env.SCRAPELESS_API_KEY,
  sessionTTL: '300',
});
const browser = await chromium.connectOverCDP(endpoint);
const context = browser.contexts()[0];
const page = context.pages()[0] || await context.newPage();

const fixture = `<!doctype html><meta charset=utf-8><title>validation</title>
<form id=f>
  <input id=email name=email type=email required>
  <input id=code name=code type=text required minlength=4>
  <button type=submit>Send</button>
</form>
<script>
window.__submitted = false;
document.getElementById('f').addEventListener('submit', function(e){
  e.preventDefault(); window.__submitted = true;
});
</script>`;
await page.goto('data:text/html;charset=utf-8,' + encodeURIComponent(fixture),
  { waitUntil: 'load' });

await page.fill('#email', 'not-an-address');
await page.fill('#code', 'ab');

const report = await page.evaluate(() => {
  const form = document.getElementById('f');
  form.requestSubmit();
  return {
    submitted: window.__submitted,
    fields: [...form.elements]
      .filter(el => el.willValidate && !el.checkValidity())
      .map(el => ({
        name: el.name,
        message: el.validationMessage,
        failed: Object.keys(ValidityState.prototype)
          .filter(k => k !== 'valid' && el.validity[k]),
      })),
  };
});
console.log(JSON.stringify(report, null, 1));
await browser.close();

{
 "submitted": false,
 "fields": [
  {
   "name": "email",
   "message": "Please include an '@' in the email address. 'not-an-address' is missing an '@'.",
   "failed": [
    "typeMismatch"
   ]
  },
  {
   "name": "code",
   "message": "Please lengthen this text to 4 characters or more (you are currently using 2 characters).",
   "failed": [
    "tooShort"
   ]
  }
 ]
}

submitted is false because the browser blocked the submission before the handler ran, and each failing field names its own broken rule. That gives you a machine-readable reason to log instead of an unexplained absence of results. MDN reference on client-side form validation covers the wider set of constraints these flags map onto.

Pages that render their own error text rather than relying on the browser are the case the first measurement already explained: those messages appear only if the events they listen for were dispatched.

Where a local browser runs out

Every technique above is ordinary Playwright and runs against a local Chromium too. The Playwright input documentation describes the same methods. What a local browser does not give you is a consistent environment for the form to be evaluated in.

Forms are the part of a site most closely tied to fraud and abuse controls, and those controls look at the session rather than the markup: the egress address, the fingerprint, and whether the browser presents as a genuine installation. That is the part Scrapeless Scraping Browser supplies: a customizable, anti-detection cloud browser powered by self-developed Chromium, configured per session at connect time through parameters such as sessionTTL, all behind the same connectOverCDP call your code already uses. Nothing in the widget handling changes; only the environment does. The Scraping Browser product page and the documentation cover the full session surface.

Troubleshooting

Conclusion

Form automation problems that look mysterious are usually one measurable thing: a value that exists in the DOM without the events that make the page notice it. Direct assignment sets the value, satisfies constraint validation, and populates FormData — and tells nobody. Locator methods such as fill, check, and selectOption emit what the page is listening for, which is why they keep working when a form grows a dependent field, a picker widget, or a validation layer.

Build the habit of confirming the outcome rather than the input: read the committed value back from a widget, wait for the element a change was supposed to reveal, and inspect validity when a submission goes nowhere. Running on Scrapeless Scraping Browser keeps the environment consistent underneath all of it, so the only variable left is your selector logic.

Ready to Build Your AI-Powered Data Pipeline?

Join the community to claim a free plan and compare notes with developers automating form-driven workflows: Discord · Telegram.

Sign up at app.scrapeless.com for free Scraping Browser runtime, and see pricing when you scale up.

FAQ

Q: Does setting element.value directly ever work?
Yes, for forms that read the DOM at submit time. In the measured run, direct assignment populated FormData and passed constraint validation. It fails wherever the page keeps its own copy of the state or renders anything from an input or change listener, because assignment dispatches no events.

Q: What events do I need to dispatch if I must set a value manually?
Dispatch a bubbling input event for text fields and a bubbling change event for selects, checkboxes, and radios. Some frameworks track the previous value on the element and ignore an event whose value they believe they already recorded; calling the native prototype setter before dispatching avoids that. Using fill(), check(), or selectOption() sidesteps the issue entirely.

Q: Why is my date field empty after I filled it?
A JavaScript calendar widget most likely reverted it. Filling the field and then pressing Escape or clicking elsewhere returned an empty string in testing, because the widget treats a dismissed overlay as an abandoned edit. Commit the value with Enter and read it back before submitting.

Q: Can I upload a file when the browser runs in the cloud?
Yes. setInputFiles() transfers the local file to the remote session over the protocol, so no operating-system file dialog is involved. The populated FileList and the submitted form data both confirm the upload.

Q: How do I tell why a form refused to submit?
Iterate the form's elements, filter for those where checkValidity() returns false, and read each one's validationMessage and validity flags. That gives you the specific failed constraint, such as typeMismatch or tooShort, without inspecting rendered pixels.

Q: Should I use fill() or type character by character?
Prefer fill(). It emits focus, beforeinput, and input, which is what almost every form listens for. Reach for per-character entry only when the page reacts to individual keystrokes, such as an autocomplete that queries on each letter — and check the result, since some widgets reformat the field between keystrokes.