fix(js): initialize a model added after the document is ready

[66Ton99]

Problem

addModel(model, onLoad) defers registration to onDocumentReady(), and that helper only adds a DOMContentLoaded listener:

this.onDocumentReady=function(callback){varaddListener=document.addEventListener||document.attachEvent;
...
addListener.call(document,eventName,function(callee){ ... callback();},false)};

When a page fetches a rendered form after the initial load and injects it — a single page CRUD, a modal that loads its form, a wizard step — the addModel() call the fragment carries runs when DOMContentLoaded has already been dispatched. The listener is never called, so the form is registered nowhere and keeps no validator at all.

The default of init_js_validation(form) is onLoad = true, so this is the path a fragment hits unless the application knows to pass false. onLoad = false is affected too, in a smaller way: it registers the model right away but still defers disableNativeValidationUi() through the same helper, so with html5_validation: true an injected form keeps the native bubble that stops the submit event this library listens to.

Change

onDocumentReady() runs the callback immediately once document.readyState is past loading, and still waits for the event while the document is being parsed, so the initial page load is unchanged — a model printed inline is still initialized after the document is ready, which is what lets js_validator_config() appear further down the page.

Tests

Two Jest tests in SvarohJsFormValidator.test.js: a model added while the document is ready registers its form, and a model added while document.readyState is loading still waits for the event. The first fails on main.

npx jest — 610 tests pass (608 before). PHP checks are untouched by this change; the host PHP here is 8.3, below the ^8.4 requirement, so composer test was not run.

🤖 Generated with Claude Code

[66Ton99]

Follow-up from review — b7c40c6

A review of the first commit turned up three things the change either introduced or left standing.

interactive is not a document that is done

The immediate branch fired for every state past loading. But interactive means the document is parsed while its deferred scripts still run, and DOMContentLoaded has not been dispatched yet.

That matters because onDocumentReady() does double duty in addModel(). The second call, on the onLoad = false branch, is not a DOM-readiness check at all — it is an ordering barrier, holding disableNativeValidationUi() until a js_validator_config() printed further down the document has set config. A defer or type="module" script would have lost that barrier and left the form without novalidate under html5_validation: true.

The condition is now 'complete' === document.readyState, the only state where the event really is gone. It happens to be what old IE needs too: there interactive does not mean the tree can be walked yet, which is why jQuery pairs its check with documentElement.doScroll.

The listener was never removed

Pre-existing, but the change lives in that function:

addListener.call(document,eventName,function(callee){removeListener.call(this,eventName,callee,false);

callee is the event, not the handler, so removeEventListener() matched nothing and every call left a listener behind. attachEvent passes no argument at all and binds this to window, so the fallback path was broken twice over and ran its callback on every readystatechange instead of the last one. The handler now names itself and detaches from document.

Reopening a modal piled up instances

The scenario the first commit unlocks is a form injected more than once. registerForm() only replaced an instance when domNode was identical, so every re-injection appended one more element pointing at a node that had been taken out of the document, and getFormInstances() handed those out. Instances whose node is no longer in the document are dropped when the same form is initialized again, guarded on document.contains so a browser that cannot answer keeps the old behaviour.

Tests

withReadyState() drives the document state, since jsdom reports complete for a whole run. The existing skips a model without a DOM node on the deferred branch too had quietly stopped deferring — it registered synchronously and its dispatchEvent() was a no-op — so it stubs loading again and asserts it.

Five tests added, each verified to fail on a revert of its own fix and nothing else:

reverted	fails
the readyState condition	still waits for the document while its deferred scripts run, turns the native UI off with a configuration a deferred script sets
the named handler	leaves no listener behind once the document is ready
dropping detached instances	forgets the instance of a render that was taken out of the document

Docs

2_3.md gains two subsections: one on forms loaded after the page — including that innerHTML does not execute a <script> tag it inserts, so a fragment dropped that way is rendered and never initialized — and one holding the existing onLoad = false example. 3_20.md notes the new getFormInstances() behaviour.

Verification

Full suite in the Nix shell, PHP 8.5.6 / Node 24.16.0:

• composer test — 95 tests, 268 assertions
• composer phpstan — no errors
• npm run test:unit — 615 tests
• npm run test:coverage — 94.67% line coverage, threshold 80%
• Cypress e2e — 24/24

The e2e run earns its place here: jsdom cannot tell interactive from complete, so a real browser is the only place the ordering claim is exercised end to end.

This supersedes the test count and the "PHP checks were not run" note in the description above.

[66Ton99]

Problem

addModel(model, onLoad) defers registration to onDocumentReady(), and that helper only adds a DOMContentLoaded listener:

this.onDocumentReady=function(callback){varaddListener=document.addEventListener||document.attachEvent;
...
addListener.call(document,eventName,function(callee){ ... callback();},false)};

When a page fetches a rendered form after the initial load and injects it — a single page CRUD, a modal that loads its form, a wizard step — the addModel() call the fragment carries runs when DOMContentLoaded has already been dispatched. The listener is never called, so the form is registered nowhere and keeps no validator at all.

The default of init_js_validation(form) is onLoad = true, so this is the path a fragment hits unless the application knows to pass false. onLoad = false is affected too, in a smaller way: it registers the model right away but still defers disableNativeValidationUi() through the same helper, so with html5_validation: true an injected form keeps the native bubble that stops the submit event this library listens to.

Change

onDocumentReady() runs the callback immediately once document.readyState is past loading, and still waits for the event while the document is being parsed, so the initial page load is unchanged — a model printed inline is still initialized after the document is ready, which is what lets js_validator_config() appear further down the page.

Tests

Two Jest tests in SvarohJsFormValidator.test.js: a model added while the document is ready registers its form, and a model added while document.readyState is loading still waits for the event. The first fails on main.

npx jest — 610 tests pass (608 before). PHP checks are untouched by this change; the host PHP here is 8.3, below the ^8.4 requirement, so composer test was not run.

🤖 Generated with Claude Code

[66Ton99]

Follow-up from review — b7c40c6

A review of the first commit turned up three things the change either introduced or left standing.

interactive is not a document that is done

The immediate branch fired for every state past loading. But interactive means the document is parsed while its deferred scripts still run, and DOMContentLoaded has not been dispatched yet.

That matters because onDocumentReady() does double duty in addModel(). The second call, on the onLoad = false branch, is not a DOM-readiness check at all — it is an ordering barrier, holding disableNativeValidationUi() until a js_validator_config() printed further down the document has set config. A defer or type="module" script would have lost that barrier and left the form without novalidate under html5_validation: true.

The condition is now 'complete' === document.readyState, the only state where the event really is gone. It happens to be what old IE needs too: there interactive does not mean the tree can be walked yet, which is why jQuery pairs its check with documentElement.doScroll.

The listener was never removed

Pre-existing, but the change lives in that function:

addListener.call(document,eventName,function(callee){removeListener.call(this,eventName,callee,false);

callee is the event, not the handler, so removeEventListener() matched nothing and every call left a listener behind. attachEvent passes no argument at all and binds this to window, so the fallback path was broken twice over and ran its callback on every readystatechange instead of the last one. The handler now names itself and detaches from document.

Reopening a modal piled up instances

The scenario the first commit unlocks is a form injected more than once. registerForm() only replaced an instance when domNode was identical, so every re-injection appended one more element pointing at a node that had been taken out of the document, and getFormInstances() handed those out. Instances whose node is no longer in the document are dropped when the same form is initialized again, guarded on document.contains so a browser that cannot answer keeps the old behaviour.

Tests

withReadyState() drives the document state, since jsdom reports complete for a whole run. The existing skips a model without a DOM node on the deferred branch too had quietly stopped deferring — it registered synchronously and its dispatchEvent() was a no-op — so it stubs loading again and asserts it.

Five tests added, each verified to fail on a revert of its own fix and nothing else:

reverted	fails
the readyState condition	still waits for the document while its deferred scripts run, turns the native UI off with a configuration a deferred script sets
the named handler	leaves no listener behind once the document is ready
dropping detached instances	forgets the instance of a render that was taken out of the document

Docs

2_3.md gains two subsections: one on forms loaded after the page — including that innerHTML does not execute a <script> tag it inserts, so a fragment dropped that way is rendered and never initialized — and one holding the existing onLoad = false example. 3_20.md notes the new getFormInstances() behaviour.

Verification

Full suite in the Nix shell, PHP 8.5.6 / Node 24.16.0:

• composer test — 95 tests, 268 assertions
• composer phpstan — no errors
• npm run test:unit — 615 tests
• npm run test:coverage — 94.67% line coverage, threshold 80%
• Cypress e2e — 24/24

The e2e run earns its place here: jsdom cannot tell interactive from complete, so a real browser is the only place the ordering claim is exercised end to end.

This supersedes the test count and the "PHP checks were not run" note in the description above.

[66Ton99]

Problem

addModel(model, onLoad) defers registration to onDocumentReady(), and that helper only adds a DOMContentLoaded listener:

this.onDocumentReady=function(callback){varaddListener=document.addEventListener||document.attachEvent;
...
addListener.call(document,eventName,function(callee){ ... callback();},false)};

When a page fetches a rendered form after the initial load and injects it — a single page CRUD, a modal that loads its form, a wizard step — the addModel() call the fragment carries runs when DOMContentLoaded has already been dispatched. The listener is never called, so the form is registered nowhere and keeps no validator at all.

The default of init_js_validation(form) is onLoad = true, so this is the path a fragment hits unless the application knows to pass false. onLoad = false is affected too, in a smaller way: it registers the model right away but still defers disableNativeValidationUi() through the same helper, so with html5_validation: true an injected form keeps the native bubble that stops the submit event this library listens to.

Change

onDocumentReady() runs the callback immediately once document.readyState is past loading, and still waits for the event while the document is being parsed, so the initial page load is unchanged — a model printed inline is still initialized after the document is ready, which is what lets js_validator_config() appear further down the page.

Tests

Two Jest tests in SvarohJsFormValidator.test.js: a model added while the document is ready registers its form, and a model added while document.readyState is loading still waits for the event. The first fails on main.

npx jest — 610 tests pass (608 before). PHP checks are untouched by this change; the host PHP here is 8.3, below the ^8.4 requirement, so composer test was not run.

🤖 Generated with Claude Code

[66Ton99]

Follow-up from review — b7c40c6

A review of the first commit turned up three things the change either introduced or left standing.

interactive is not a document that is done

The immediate branch fired for every state past loading. But interactive means the document is parsed while its deferred scripts still run, and DOMContentLoaded has not been dispatched yet.

That matters because onDocumentReady() does double duty in addModel(). The second call, on the onLoad = false branch, is not a DOM-readiness check at all — it is an ordering barrier, holding disableNativeValidationUi() until a js_validator_config() printed further down the document has set config. A defer or type="module" script would have lost that barrier and left the form without novalidate under html5_validation: true.

The condition is now 'complete' === document.readyState, the only state where the event really is gone. It happens to be what old IE needs too: there interactive does not mean the tree can be walked yet, which is why jQuery pairs its check with documentElement.doScroll.

The listener was never removed

Pre-existing, but the change lives in that function:

addListener.call(document,eventName,function(callee){removeListener.call(this,eventName,callee,false);

callee is the event, not the handler, so removeEventListener() matched nothing and every call left a listener behind. attachEvent passes no argument at all and binds this to window, so the fallback path was broken twice over and ran its callback on every readystatechange instead of the last one. The handler now names itself and detaches from document.

Reopening a modal piled up instances

The scenario the first commit unlocks is a form injected more than once. registerForm() only replaced an instance when domNode was identical, so every re-injection appended one more element pointing at a node that had been taken out of the document, and getFormInstances() handed those out. Instances whose node is no longer in the document are dropped when the same form is initialized again, guarded on document.contains so a browser that cannot answer keeps the old behaviour.

Tests

withReadyState() drives the document state, since jsdom reports complete for a whole run. The existing skips a model without a DOM node on the deferred branch too had quietly stopped deferring — it registered synchronously and its dispatchEvent() was a no-op — so it stubs loading again and asserts it.

Five tests added, each verified to fail on a revert of its own fix and nothing else:

reverted	fails
the readyState condition	still waits for the document while its deferred scripts run, turns the native UI off with a configuration a deferred script sets
the named handler	leaves no listener behind once the document is ready
dropping detached instances	forgets the instance of a render that was taken out of the document

Docs

2_3.md gains two subsections: one on forms loaded after the page — including that innerHTML does not execute a <script> tag it inserts, so a fragment dropped that way is rendered and never initialized — and one holding the existing onLoad = false example. 3_20.md notes the new getFormInstances() behaviour.

Verification

Full suite in the Nix shell, PHP 8.5.6 / Node 24.16.0:

• composer test — 95 tests, 268 assertions
• composer phpstan — no errors
• npm run test:unit — 615 tests
• npm run test:coverage — 94.67% line coverage, threshold 80%
• Cypress e2e — 24/24

The e2e run earns its place here: jsdom cannot tell interactive from complete, so a real browser is the only place the ordering claim is exercised end to end.

This supersedes the test count and the "PHP checks were not run" note in the description above.

[66Ton99]

Problem

addModel(model, onLoad) defers registration to onDocumentReady(), and that helper only adds a DOMContentLoaded listener:

this.onDocumentReady=function(callback){varaddListener=document.addEventListener||document.attachEvent;
...
addListener.call(document,eventName,function(callee){ ... callback();},false)};

When a page fetches a rendered form after the initial load and injects it — a single page CRUD, a modal that loads its form, a wizard step — the addModel() call the fragment carries runs when DOMContentLoaded has already been dispatched. The listener is never called, so the form is registered nowhere and keeps no validator at all.

The default of init_js_validation(form) is onLoad = true, so this is the path a fragment hits unless the application knows to pass false. onLoad = false is affected too, in a smaller way: it registers the model right away but still defers disableNativeValidationUi() through the same helper, so with html5_validation: true an injected form keeps the native bubble that stops the submit event this library listens to.

Change

onDocumentReady() runs the callback immediately once document.readyState is past loading, and still waits for the event while the document is being parsed, so the initial page load is unchanged — a model printed inline is still initialized after the document is ready, which is what lets js_validator_config() appear further down the page.

Tests

Two Jest tests in SvarohJsFormValidator.test.js: a model added while the document is ready registers its form, and a model added while document.readyState is loading still waits for the event. The first fails on main.

npx jest — 610 tests pass (608 before). PHP checks are untouched by this change; the host PHP here is 8.3, below the ^8.4 requirement, so composer test was not run.

🤖 Generated with Claude Code

[66Ton99]

Follow-up from review — b7c40c6

A review of the first commit turned up three things the change either introduced or left standing.

interactive is not a document that is done

The immediate branch fired for every state past loading. But interactive means the document is parsed while its deferred scripts still run, and DOMContentLoaded has not been dispatched yet.

That matters because onDocumentReady() does double duty in addModel(). The second call, on the onLoad = false branch, is not a DOM-readiness check at all — it is an ordering barrier, holding disableNativeValidationUi() until a js_validator_config() printed further down the document has set config. A defer or type="module" script would have lost that barrier and left the form without novalidate under html5_validation: true.

The condition is now 'complete' === document.readyState, the only state where the event really is gone. It happens to be what old IE needs too: there interactive does not mean the tree can be walked yet, which is why jQuery pairs its check with documentElement.doScroll.

The listener was never removed

Pre-existing, but the change lives in that function:

addListener.call(document,eventName,function(callee){removeListener.call(this,eventName,callee,false);

callee is the event, not the handler, so removeEventListener() matched nothing and every call left a listener behind. attachEvent passes no argument at all and binds this to window, so the fallback path was broken twice over and ran its callback on every readystatechange instead of the last one. The handler now names itself and detaches from document.

Reopening a modal piled up instances

The scenario the first commit unlocks is a form injected more than once. registerForm() only replaced an instance when domNode was identical, so every re-injection appended one more element pointing at a node that had been taken out of the document, and getFormInstances() handed those out. Instances whose node is no longer in the document are dropped when the same form is initialized again, guarded on document.contains so a browser that cannot answer keeps the old behaviour.

Tests

withReadyState() drives the document state, since jsdom reports complete for a whole run. The existing skips a model without a DOM node on the deferred branch too had quietly stopped deferring — it registered synchronously and its dispatchEvent() was a no-op — so it stubs loading again and asserts it.

Five tests added, each verified to fail on a revert of its own fix and nothing else:

reverted	fails
the readyState condition	still waits for the document while its deferred scripts run, turns the native UI off with a configuration a deferred script sets
the named handler	leaves no listener behind once the document is ready
dropping detached instances	forgets the instance of a render that was taken out of the document

Docs

2_3.md gains two subsections: one on forms loaded after the page — including that innerHTML does not execute a <script> tag it inserts, so a fragment dropped that way is rendered and never initialized — and one holding the existing onLoad = false example. 3_20.md notes the new getFormInstances() behaviour.

Verification

Full suite in the Nix shell, PHP 8.5.6 / Node 24.16.0:

• composer test — 95 tests, 268 assertions
• composer phpstan — no errors
• npm run test:unit — 615 tests
• npm run test:coverage — 94.67% line coverage, threshold 80%
• Cypress e2e — 24/24

The e2e run earns its place here: jsdom cannot tell interactive from complete, so a real browser is the only place the ordering claim is exercised end to end.

This supersedes the test count and the "PHP checks were not run" note in the description above.

[66Ton99]

Problem

addModel(model, onLoad) defers registration to onDocumentReady(), and that helper only adds a DOMContentLoaded listener:

this.onDocumentReady=function(callback){varaddListener=document.addEventListener||document.attachEvent;
...
addListener.call(document,eventName,function(callee){ ... callback();},false)};

When a page fetches a rendered form after the initial load and injects it — a single page CRUD, a modal that loads its form, a wizard step — the addModel() call the fragment carries runs when DOMContentLoaded has already been dispatched. The listener is never called, so the form is registered nowhere and keeps no validator at all.

The default of init_js_validation(form) is onLoad = true, so this is the path a fragment hits unless the application knows to pass false. onLoad = false is affected too, in a smaller way: it registers the model right away but still defers disableNativeValidationUi() through the same helper, so with html5_validation: true an injected form keeps the native bubble that stops the submit event this library listens to.

Change

onDocumentReady() runs the callback immediately once document.readyState is past loading, and still waits for the event while the document is being parsed, so the initial page load is unchanged — a model printed inline is still initialized after the document is ready, which is what lets js_validator_config() appear further down the page.

Tests

Two Jest tests in SvarohJsFormValidator.test.js: a model added while the document is ready registers its form, and a model added while document.readyState is loading still waits for the event. The first fails on main.

npx jest — 610 tests pass (608 before). PHP checks are untouched by this change; the host PHP here is 8.3, below the ^8.4 requirement, so composer test was not run.

🤖 Generated with Claude Code

[66Ton99]

Follow-up from review — b7c40c6

A review of the first commit turned up three things the change either introduced or left standing.

interactive is not a document that is done

The immediate branch fired for every state past loading. But interactive means the document is parsed while its deferred scripts still run, and DOMContentLoaded has not been dispatched yet.

That matters because onDocumentReady() does double duty in addModel(). The second call, on the onLoad = false branch, is not a DOM-readiness check at all — it is an ordering barrier, holding disableNativeValidationUi() until a js_validator_config() printed further down the document has set config. A defer or type="module" script would have lost that barrier and left the form without novalidate under html5_validation: true.

The condition is now 'complete' === document.readyState, the only state where the event really is gone. It happens to be what old IE needs too: there interactive does not mean the tree can be walked yet, which is why jQuery pairs its check with documentElement.doScroll.

The listener was never removed

Pre-existing, but the change lives in that function:

addListener.call(document,eventName,function(callee){removeListener.call(this,eventName,callee,false);

callee is the event, not the handler, so removeEventListener() matched nothing and every call left a listener behind. attachEvent passes no argument at all and binds this to window, so the fallback path was broken twice over and ran its callback on every readystatechange instead of the last one. The handler now names itself and detaches from document.

Reopening a modal piled up instances

The scenario the first commit unlocks is a form injected more than once. registerForm() only replaced an instance when domNode was identical, so every re-injection appended one more element pointing at a node that had been taken out of the document, and getFormInstances() handed those out. Instances whose node is no longer in the document are dropped when the same form is initialized again, guarded on document.contains so a browser that cannot answer keeps the old behaviour.

Tests

withReadyState() drives the document state, since jsdom reports complete for a whole run. The existing skips a model without a DOM node on the deferred branch too had quietly stopped deferring — it registered synchronously and its dispatchEvent() was a no-op — so it stubs loading again and asserts it.

Five tests added, each verified to fail on a revert of its own fix and nothing else:

reverted	fails
the readyState condition	still waits for the document while its deferred scripts run, turns the native UI off with a configuration a deferred script sets
the named handler	leaves no listener behind once the document is ready
dropping detached instances	forgets the instance of a render that was taken out of the document

Docs

2_3.md gains two subsections: one on forms loaded after the page — including that innerHTML does not execute a <script> tag it inserts, so a fragment dropped that way is rendered and never initialized — and one holding the existing onLoad = false example. 3_20.md notes the new getFormInstances() behaviour.

Verification

Full suite in the Nix shell, PHP 8.5.6 / Node 24.16.0:

• composer test — 95 tests, 268 assertions
• composer phpstan — no errors
• npm run test:unit — 615 tests
• npm run test:coverage — 94.67% line coverage, threshold 80%
• Cypress e2e — 24/24

The e2e run earns its place here: jsdom cannot tell interactive from complete, so a real browser is the only place the ordering claim is exercised end to end.

This supersedes the test count and the "PHP checks were not run" note in the description above.

[66Ton99]

Problem

addModel(model, onLoad) defers registration to onDocumentReady(), and that helper only adds a DOMContentLoaded listener:

this.onDocumentReady=function(callback){varaddListener=document.addEventListener||document.attachEvent;
...
addListener.call(document,eventName,function(callee){ ... callback();},false)};

When a page fetches a rendered form after the initial load and injects it — a single page CRUD, a modal that loads its form, a wizard step — the addModel() call the fragment carries runs when DOMContentLoaded has already been dispatched. The listener is never called, so the form is registered nowhere and keeps no validator at all.

The default of init_js_validation(form) is onLoad = true, so this is the path a fragment hits unless the application knows to pass false. onLoad = false is affected too, in a smaller way: it registers the model right away but still defers disableNativeValidationUi() through the same helper, so with html5_validation: true an injected form keeps the native bubble that stops the submit event this library listens to.

Change

onDocumentReady() runs the callback immediately once document.readyState is past loading, and still waits for the event while the document is being parsed, so the initial page load is unchanged — a model printed inline is still initialized after the document is ready, which is what lets js_validator_config() appear further down the page.

Tests

Two Jest tests in SvarohJsFormValidator.test.js: a model added while the document is ready registers its form, and a model added while document.readyState is loading still waits for the event. The first fails on main.

npx jest — 610 tests pass (608 before). PHP checks are untouched by this change; the host PHP here is 8.3, below the ^8.4 requirement, so composer test was not run.

🤖 Generated with Claude Code

[66Ton99]

Follow-up from review — b7c40c6

A review of the first commit turned up three things the change either introduced or left standing.

interactive is not a document that is done

The immediate branch fired for every state past loading. But interactive means the document is parsed while its deferred scripts still run, and DOMContentLoaded has not been dispatched yet.

That matters because onDocumentReady() does double duty in addModel(). The second call, on the onLoad = false branch, is not a DOM-readiness check at all — it is an ordering barrier, holding disableNativeValidationUi() until a js_validator_config() printed further down the document has set config. A defer or type="module" script would have lost that barrier and left the form without novalidate under html5_validation: true.

The condition is now 'complete' === document.readyState, the only state where the event really is gone. It happens to be what old IE needs too: there interactive does not mean the tree can be walked yet, which is why jQuery pairs its check with documentElement.doScroll.

The listener was never removed

Pre-existing, but the change lives in that function:

addListener.call(document,eventName,function(callee){removeListener.call(this,eventName,callee,false);

callee is the event, not the handler, so removeEventListener() matched nothing and every call left a listener behind. attachEvent passes no argument at all and binds this to window, so the fallback path was broken twice over and ran its callback on every readystatechange instead of the last one. The handler now names itself and detaches from document.

Reopening a modal piled up instances

The scenario the first commit unlocks is a form injected more than once. registerForm() only replaced an instance when domNode was identical, so every re-injection appended one more element pointing at a node that had been taken out of the document, and getFormInstances() handed those out. Instances whose node is no longer in the document are dropped when the same form is initialized again, guarded on document.contains so a browser that cannot answer keeps the old behaviour.

Tests

withReadyState() drives the document state, since jsdom reports complete for a whole run. The existing skips a model without a DOM node on the deferred branch too had quietly stopped deferring — it registered synchronously and its dispatchEvent() was a no-op — so it stubs loading again and asserts it.

Five tests added, each verified to fail on a revert of its own fix and nothing else:

reverted	fails
the readyState condition	still waits for the document while its deferred scripts run, turns the native UI off with a configuration a deferred script sets
the named handler	leaves no listener behind once the document is ready
dropping detached instances	forgets the instance of a render that was taken out of the document

Docs

2_3.md gains two subsections: one on forms loaded after the page — including that innerHTML does not execute a <script> tag it inserts, so a fragment dropped that way is rendered and never initialized — and one holding the existing onLoad = false example. 3_20.md notes the new getFormInstances() behaviour.

Verification

Full suite in the Nix shell, PHP 8.5.6 / Node 24.16.0:

• composer test — 95 tests, 268 assertions
• composer phpstan — no errors
• npm run test:unit — 615 tests
• npm run test:coverage — 94.67% line coverage, threshold 80%
• Cypress e2e — 24/24

The e2e run earns its place here: jsdom cannot tell interactive from complete, so a real browser is the only place the ordering claim is exercised end to end.

This supersedes the test count and the "PHP checks were not run" note in the description above.

[66Ton99]

Problem

addModel(model, onLoad) defers registration to onDocumentReady(), and that helper only adds a DOMContentLoaded listener:

this.onDocumentReady=function(callback){varaddListener=document.addEventListener||document.attachEvent;
...
addListener.call(document,eventName,function(callee){ ... callback();},false)};

When a page fetches a rendered form after the initial load and injects it — a single page CRUD, a modal that loads its form, a wizard step — the addModel() call the fragment carries runs when DOMContentLoaded has already been dispatched. The listener is never called, so the form is registered nowhere and keeps no validator at all.

The default of init_js_validation(form) is onLoad = true, so this is the path a fragment hits unless the application knows to pass false. onLoad = false is affected too, in a smaller way: it registers the model right away but still defers disableNativeValidationUi() through the same helper, so with html5_validation: true an injected form keeps the native bubble that stops the submit event this library listens to.

Change

onDocumentReady() runs the callback immediately once document.readyState is past loading, and still waits for the event while the document is being parsed, so the initial page load is unchanged — a model printed inline is still initialized after the document is ready, which is what lets js_validator_config() appear further down the page.

Tests

Two Jest tests in SvarohJsFormValidator.test.js: a model added while the document is ready registers its form, and a model added while document.readyState is loading still waits for the event. The first fails on main.

npx jest — 610 tests pass (608 before). PHP checks are untouched by this change; the host PHP here is 8.3, below the ^8.4 requirement, so composer test was not run.

🤖 Generated with Claude Code

[66Ton99]

Follow-up from review — b7c40c6

A review of the first commit turned up three things the change either introduced or left standing.

interactive is not a document that is done

The immediate branch fired for every state past loading. But interactive means the document is parsed while its deferred scripts still run, and DOMContentLoaded has not been dispatched yet.

That matters because onDocumentReady() does double duty in addModel(). The second call, on the onLoad = false branch, is not a DOM-readiness check at all — it is an ordering barrier, holding disableNativeValidationUi() until a js_validator_config() printed further down the document has set config. A defer or type="module" script would have lost that barrier and left the form without novalidate under html5_validation: true.

The condition is now 'complete' === document.readyState, the only state where the event really is gone. It happens to be what old IE needs too: there interactive does not mean the tree can be walked yet, which is why jQuery pairs its check with documentElement.doScroll.

The listener was never removed

Pre-existing, but the change lives in that function:

addListener.call(document,eventName,function(callee){removeListener.call(this,eventName,callee,false);

callee is the event, not the handler, so removeEventListener() matched nothing and every call left a listener behind. attachEvent passes no argument at all and binds this to window, so the fallback path was broken twice over and ran its callback on every readystatechange instead of the last one. The handler now names itself and detaches from document.

Reopening a modal piled up instances

The scenario the first commit unlocks is a form injected more than once. registerForm() only replaced an instance when domNode was identical, so every re-injection appended one more element pointing at a node that had been taken out of the document, and getFormInstances() handed those out. Instances whose node is no longer in the document are dropped when the same form is initialized again, guarded on document.contains so a browser that cannot answer keeps the old behaviour.

Tests

withReadyState() drives the document state, since jsdom reports complete for a whole run. The existing skips a model without a DOM node on the deferred branch too had quietly stopped deferring — it registered synchronously and its dispatchEvent() was a no-op — so it stubs loading again and asserts it.

Five tests added, each verified to fail on a revert of its own fix and nothing else:

reverted	fails
the readyState condition	still waits for the document while its deferred scripts run, turns the native UI off with a configuration a deferred script sets
the named handler	leaves no listener behind once the document is ready
dropping detached instances	forgets the instance of a render that was taken out of the document

Docs

2_3.md gains two subsections: one on forms loaded after the page — including that innerHTML does not execute a <script> tag it inserts, so a fragment dropped that way is rendered and never initialized — and one holding the existing onLoad = false example. 3_20.md notes the new getFormInstances() behaviour.

Verification

Full suite in the Nix shell, PHP 8.5.6 / Node 24.16.0:

• composer test — 95 tests, 268 assertions
• composer phpstan — no errors
• npm run test:unit — 615 tests
• npm run test:coverage — 94.67% line coverage, threshold 80%
• Cypress e2e — 24/24

The e2e run earns its place here: jsdom cannot tell interactive from complete, so a real browser is the only place the ordering claim is exercised end to end.

This supersedes the test count and the "PHP checks were not run" note in the description above.

[66Ton99]

Problem

addModel(model, onLoad) defers registration to onDocumentReady(), and that helper only adds a DOMContentLoaded listener:

this.onDocumentReady=function(callback){varaddListener=document.addEventListener||document.attachEvent;
...
addListener.call(document,eventName,function(callee){ ... callback();},false)};

When a page fetches a rendered form after the initial load and injects it — a single page CRUD, a modal that loads its form, a wizard step — the addModel() call the fragment carries runs when DOMContentLoaded has already been dispatched. The listener is never called, so the form is registered nowhere and keeps no validator at all.

The default of init_js_validation(form) is onLoad = true, so this is the path a fragment hits unless the application knows to pass false. onLoad = false is affected too, in a smaller way: it registers the model right away but still defers disableNativeValidationUi() through the same helper, so with html5_validation: true an injected form keeps the native bubble that stops the submit event this library listens to.

Change

onDocumentReady() runs the callback immediately once document.readyState is past loading, and still waits for the event while the document is being parsed, so the initial page load is unchanged — a model printed inline is still initialized after the document is ready, which is what lets js_validator_config() appear further down the page.

Tests

Two Jest tests in SvarohJsFormValidator.test.js: a model added while the document is ready registers its form, and a model added while document.readyState is loading still waits for the event. The first fails on main.

npx jest — 610 tests pass (608 before). PHP checks are untouched by this change; the host PHP here is 8.3, below the ^8.4 requirement, so composer test was not run.

🤖 Generated with Claude Code

[66Ton99]

Follow-up from review — b7c40c6

A review of the first commit turned up three things the change either introduced or left standing.

interactive is not a document that is done

The immediate branch fired for every state past loading. But interactive means the document is parsed while its deferred scripts still run, and DOMContentLoaded has not been dispatched yet.

That matters because onDocumentReady() does double duty in addModel(). The second call, on the onLoad = false branch, is not a DOM-readiness check at all — it is an ordering barrier, holding disableNativeValidationUi() until a js_validator_config() printed further down the document has set config. A defer or type="module" script would have lost that barrier and left the form without novalidate under html5_validation: true.

The condition is now 'complete' === document.readyState, the only state where the event really is gone. It happens to be what old IE needs too: there interactive does not mean the tree can be walked yet, which is why jQuery pairs its check with documentElement.doScroll.

The listener was never removed

Pre-existing, but the change lives in that function:

addListener.call(document,eventName,function(callee){removeListener.call(this,eventName,callee,false);

callee is the event, not the handler, so removeEventListener() matched nothing and every call left a listener behind. attachEvent passes no argument at all and binds this to window, so the fallback path was broken twice over and ran its callback on every readystatechange instead of the last one. The handler now names itself and detaches from document.

Reopening a modal piled up instances

The scenario the first commit unlocks is a form injected more than once. registerForm() only replaced an instance when domNode was identical, so every re-injection appended one more element pointing at a node that had been taken out of the document, and getFormInstances() handed those out. Instances whose node is no longer in the document are dropped when the same form is initialized again, guarded on document.contains so a browser that cannot answer keeps the old behaviour.

Tests

withReadyState() drives the document state, since jsdom reports complete for a whole run. The existing skips a model without a DOM node on the deferred branch too had quietly stopped deferring — it registered synchronously and its dispatchEvent() was a no-op — so it stubs loading again and asserts it.

Five tests added, each verified to fail on a revert of its own fix and nothing else:

reverted	fails
the readyState condition	still waits for the document while its deferred scripts run, turns the native UI off with a configuration a deferred script sets
the named handler	leaves no listener behind once the document is ready
dropping detached instances	forgets the instance of a render that was taken out of the document

Docs

2_3.md gains two subsections: one on forms loaded after the page — including that innerHTML does not execute a <script> tag it inserts, so a fragment dropped that way is rendered and never initialized — and one holding the existing onLoad = false example. 3_20.md notes the new getFormInstances() behaviour.

Verification

Full suite in the Nix shell, PHP 8.5.6 / Node 24.16.0:

• composer test — 95 tests, 268 assertions
• composer phpstan — no errors
• npm run test:unit — 615 tests
• npm run test:coverage — 94.67% line coverage, threshold 80%
• Cypress e2e — 24/24

The e2e run earns its place here: jsdom cannot tell interactive from complete, so a real browser is the only place the ordering claim is exercised end to end.

This supersedes the test count and the "PHP checks were not run" note in the description above.