A legacy-browser reconstruction project focused on recovering the exact form values posted by a retired Windows line-of-business application that embedded Internet Explorer.
The application was used by a customs brokerage to lodge import, export, and amendment entries. Its gateway no longer has copies of the original POST bodies, but the client screens and a journal of the values keyed by clerks remain.
The objective is to reproduce what the embedded Internet Explorer control actually placed into each named form control immediately before submission.
The archived client displayed several HTML entry screens inside a .NET Windows Forms WebBrowser control.
When a clerk clicked Lodge entry, JavaScript on the page:
keyed controls
↓
legacy JavaScript processing
↓
hidden-field updates
↓
DOM value changes
↓
form submission
The reconstruction must reproduce the state at the bottom of that pipeline.
This is not simply a matter of copying values from the journal. The scripts transform those values, and their behavior depends on the Internet Explorer document mode in which each screen ran.
ie-mode-postback/
├── environment/
├── solution/
├── tests/
├── instruction.md
└── task.toml
Defines the historical client scenario, available evidence, required artifact, and exact output semantics.
Contains the archived client screens, scripts, journal, and supporting data.
Contains the reference reconstruction implementation.
Contains the independent verifier.
Defines task metadata and execution configuration.
The client screens are available under:
/app/data/client
The keyed-entry journal is:
/app/data/journal.jsonl
Supporting information about the archived client, workstations, and journal is documented in:
/app/data/README.md
Each journal entry records the screen that was active and the value of each control when the clerk performed the submission.
The three screens do not execute under identical Internet Explorer behavior.
Their effective document modes must be reconstructed from the HTML and the behavior of the embedded browser control.
Examples include:
- IE7-compatible behavior
- IE8 document mode
- IE11 / edge mode
A compatibility declaration does not automatically take effect if it appears too late in the document.
For example, an X-UA-Compatible declaration that follows script execution can behave differently from one declared early enough to control the document mode.
This matters because the same JavaScript can produce different results under different IE modes.
The older document modes expose Microsoft JScript semantics that differ from modern JavaScript engines.
Relevant differences include behavior around:
parseInt- regular-expression whitespace
splitsubstr- string indexing
getYeartoFixedtoDateStringtoLocaleDateStringtoLocaleStringJSON- date parsing and overflow
A modern Node.js execution of the archived scripts therefore does not reproduce the historical browser output exactly.
Internet Explorer's DOM behavior is also part of the reconstruction.
In legacy document mode, getElementById can behave differently from modern standards-oriented implementations.
In particular, older IE behavior can match elements by their name as well as their id.
That distinction can change which element a script reads or writes.
Conceptually:
<a name="txtWeight"></a>
<input id="txtWeight" name="weight">A legacy lookup can resolve differently from a modern browser lookup.
This affects downstream form values.
For every journal entry, the solver reconstructs the corresponding screen and applies the historical browser semantics.
Conceptually:
journal entry
+
screen HTML
+
screen JavaScript
+
document mode
+
legacy engine semantics
↓
final form-control values
The result must include every:
input
select
textarea
inside the form that has a name attribute.
No additional controls are included.
Hidden Fields
Several values are generated by scripts rather than directly entered by the clerk.
Examples can include:
- references
- sequence identifiers
- normalized party information
- formatted addresses
- dates
- docket descriptions
- calculated values
- serialized invoice data
These fields must reflect the value present after page scripts have executed.
Date handling is one of the major compatibility areas.
The archived client can encounter:
- US-style dates
- European-style dates
- UK-style dates
- ISO dates
- two-digit years
- month-name inputs
- overflowing month/day values
- local versus UTC interpretation
Different document modes and JavaScript engines can interpret these forms differently.
A value that modern JavaScript treats as invalid may have been accepted or normalized by the historical client.
The archived client ran in a Windows environment.
Therefore, locale-sensitive operations must reflect the historical Windows behavior rather than whatever formatting a current Linux or modern JavaScript runtime happens to use.
Examples include:
toLocaleDateString()
toLocaleString()
The task's captured environment used an English-US locale and Eastern time.
Textarea values require special attention.
In older Internet Explorer modes, text written into a textarea can normalize line endings differently from modern engines.
For example:
LF
can become:
CRLF
in the DOM value exposed by the legacy screen.
The output requires the actual control value rather than an HTTP-encoded representation.
Line breaks therefore matter character-for-character.
The journal intentionally includes realistic pasted business data.
Examples include:
- non-breaking spaces
- wide spaces
- soft hyphens
- zero-width characters
- directional characters
- German sharp s
- accented names
- international addresses
Legacy JavaScript does not always treat those characters the same way as modern ECMAScript engines.
Whitespace tests and case conversion therefore need to reflect the appropriate historical mode.
The oldest screen can depend on a JSON compatibility script rather than the browser's native JSON implementation.
That can affect which characters are escaped when structured data is serialized.
Consequently:
JSON.stringify(...)
under a modern engine is not always a valid substitute for the historical behavior.
The required artifact represents DOM control values immediately before submission.
It does not represent URL-encoded or multipart HTTP form serialization.
If a control's value is:
LINE 1
LINE 2
the JSON output must contain the actual line break representation held by the DOM.
Values are compared character-for-character.
The solver writes:
/app/output/postback.json
with the structure:
{
"entries": {
"E10001": {
"field_name": "value"
}
}
}entries must contain exactly the entry IDs present in the journal.
Each entry contains every named:
input
select
textarea
from that screen's form and nothing else.
Empty controls are represented as:
""A simplified example is:
{
"entries": {
"E10001": {
"ref": "AM-14-000001",
"ref_seq": "000001",
"party": "ACME LTD",
"addr1": "1 MAIN ST",
"docket": "AM AM-14-000001 / Mon Jan 13 2014 / 1 line(s)"
}
}
}The example only illustrates the structure. The actual entries contain all named form controls required by the archived screens.
The project contains a substantial set of historical entry records spanning:
- import entries
- export entries
- amendment entries
The task metadata describes 1,644 retained entries and more than 92,000 form values.
This scale makes manual per-record correction impractical; the historical browser behavior needs to be modeled consistently.
Modern V8 behavior differs from legacy JScript and IE document modes.
Each screen's effective document mode must be resolved independently.
IE7 mode can also match a name attribute.
Older JScript modes recognize a different whitespace set.
Legacy date parsing and two-digit-year behavior differ.
Older MSHTML modes can expose CRLF.
Legacy pages can rely on compatibility implementations such as json2.js.
The required result contains DOM values before HTTP encoding.
A high-level reconstruction can be viewed as:
journal entry
↓
select client screen
↓
determine document mode
↓
load keyed control state
↓
apply historical DOM rules
↓
execute equivalent script semantics
↓
recover named form values
↓
write postback.json
This project exercises:
- JavaScript compatibility
- Internet Explorer document modes
- Microsoft JScript
- MSHTML
- legacy DOM behavior
- HTML forms
- Windows locale formatting
- historical date handling
- Unicode normalization
- textarea line endings
- form postbacks
- frontend reverse engineering
- legacy-system migration
- deterministic state reconstruction
IE Mode Postback reconstructs the application-visible state produced by a retired browser runtime without requiring that runtime to remain available.
The central principle is:
Reproduce the semantics of the historical client, not the behavior of a modern JavaScript engine.
No license is currently specified.