Visible Field Missing from a Regional Form? Test Disabled and Readonly

A regional enquiry form displays the correct market and reference number, but the receiver says a field is missing. Before changing the residential IP, find the first point where the value disappears: live control, form entry list, outgoing request or server processing. A grey appearance is not evidence that a control will be submitted. This guide provides an authorized staging-test design; it does not claim that these tests have been run against 98IP or a customer's production form.

1. Agree on the payload contract before changing the UI

Use an owned, non-transactional test receiver that reports synthetic name-value entries without creating leads, orders or messages. Define a required text reference named reference with a fixed synthetic value REF-7. Define the expected absence or presence for each test state independently of the application's serializer. Keep the same form owner, name, value, input type and build while varying only disabled versus readonly state.

A supported control that is effectively disabled is left out of the native form entry list. An otherwise eligible named text input made readonly can still contribute its value. Readonly prevents user editing on supported controls; it is not a general replacement for disabled on every element. In particular, adding readonly to a select does not make it a native read-only select. A field without a name or associated with another form needs a separate diagnosis.

Do not infer submission behavior from grey styling, pointer-event suppression or aria-disabled alone. They do not apply native disabled form-entry rules by themselves. Likewise, a client-side read-only or hidden value is not an authorization boundary: the server must validate what the caller is allowed to submit.

2. Inspect effective state at the construction moment

Record whether the field has its own disabled attribute, whether it matches the disabled state, and whether a containing fieldset disables it. Looking only at an input's own disabled property can miss the fieldset effect. A disabled fieldset has a special exception for descendants of its first legend child; do not generalize that exception to all legends or to another disabled ancestor. Keep the primary fixture outside any legend so the basic comparison stays unambiguous.

Trace the actual application's order: validation, loading-state changes, entry-list construction, optional formdata listeners, serialization and send. Disabling the whole fieldset before constructing FormData can remove values that are still visibly present. A FormData object constructed earlier does not automatically refill itself when a field is enabled later. However, application code and formdata listeners can change its entries, so compare the final outgoing payload as well.

Use a debugger or test-only instrumentation on the owned page. Capture only synthetic field names and expected values. Constructing another FormData merely to observe the page can itself invoke formdata listeners; check for those listeners and their side effects before adding a second construction to a live flow. Do not trigger a second submission for measurement.

3. Run positive, negative and recovery cases

1. Start with the named enabled text field containing REF-7. Build the entry list through the real application path and send once to the test receiver. Expect exactly one reference entry with that value; an HTTP success alone is insufficient.
2. Keep the visible value and name unchanged, but disable that text field before construction. Expect the native entry list to omit reference. If the application contract requires it, this is the deliberate failing control that the acceptance check must detect.
3. Restore the enabled state and apply readonly to the supported text input. Confirm user editing is blocked, then compare the constructed entries and received data. Expect the reference to remain present under this fixture's other eligibility conditions.
4. Remove the field's own disabled attribute and place it in an ordinary disabled fieldset, outside the first legend. Verify that inherited effective state still excludes it. Then enable the fieldset and repeat; do not treat an absent own attribute as recovery.
5. Exercise the real loading indicator. Compare construction before versus after the UI disables the group, and test the post-error return to an editable or approved read-only state. Restore test state in the error path as well as the success path.
6. Repeat the corrected flow through the required residential region with the same build, browser preferences, account and storage state. Record the actual exit, timing and first divergent stage. These are expected outcomes until observed, not measured compatibility claims.

For a native browser submission, inspect the actual emitted request: a submit handler may disable controls before the browser constructs its entry list. For a custom JSON request, determine whether it reads application state directly or converts FormData. The native exclusion rule does not mean that every hand-written serializer will omit the same value.

4. Fix the owning stage without weakening validation

• Value is absent from the live field: inspect initialization, locale switching and asynchronous state updates.
• Value exists in the control but is absent from the entry list: check effective disabled state, form ownership, name and construction order.
• Entry exists but disappears before sending: inspect formdata listeners, explicit deletes and the JSON conversion step.
• Request contains it but the receiver does not: inspect server parsing, allowed fields and validation rather than replacing the proxy.
• Only one region fails: compare feature configuration, readiness markers and timing before attributing the difference to the exit country.

When the intended contract includes a non-editable text value, consider a supported readonly control or a validated application-state serialization design. When disabling is intentional, the receiver must accept the intended absence. Do not briefly enable every field as a universal fix; that can submit values the application deliberately excludes.

A hidden mirror is also a design change, not a harmless patch. It can become stale or create duplicate names when the original field becomes eligible again. If the owner chooses that design, specify a single source of truth, exact cardinality and server validation. Never trust a mirrored price, market entitlement or account ID simply because users cannot edit it in the normal UI.

5. Preserve a useful acceptance record

For each case keep the build and fixture ID, browser version, intended contract, effective state at construction, final entry count, synthetic receiver result and timing. Keep missing and empty distinct: no reference entry is different from an entry whose value is an empty string. A server default that silently supplies the omitted value should not make a broken client contract pass.

Retain the deliberately disabled negative case after fixing the loading sequence. Otherwise a check that only sees a success page may pass even when the field is lost again. Where submit-button identity changes the request, use the separate form submitter acceptance guide; that problem does not establish whether ordinary fields are effectively disabled.

Do not collect customer messages, cookies, authorization headers or proxy credentials in the evidence. Use small synthetic payloads and a receiver approved by the site owner. Readonly and disabled also affect interaction and validation behavior; assess those requirements separately rather than declaring the whole form accessible or secure from this payload check.

6. Use a regional route only where it answers the test

When an authorized form rollout varies by market or network perspective, consult the 98IP residential proxy product page and API configuration documentation, then configure the method supported by your account. Keep the route policy stable during a single form sequence and check actual usage. A proxy does not change the browser's form-entry algorithm or recover a field omitted before the request was sent.

• The required field, value and exact entry count are agreed independently.
• Enabled, disabled and supported readonly fixtures have distinct expectations.
• Ancestor fieldsets and the first-legend exception are understood.
• Construction timing and formdata mutations are traced to the actual request.
• Missing, empty and server-defaulted values cannot be confused.
• The corrected flow and deliberate failure are both checked across equivalent regional runs.

Does disabled="false" enable the field? No. Disabled is a Boolean attribute; remove it or set the DOM property appropriately, then check effective state including ancestors.

Can readonly preserve a select value safely? Select does not support native readonly. Choose an explicit UI and serialization design with the owner.

Should we rotate IPs when the payload omits a visible reference? First locate the omission. A value already absent from local construction is not repaired by a different exit.