Firefox 155 Opens NDJSON in JSON Viewer: A Better Proxy QA Workflow

Firefox 155 was released on September 1, 2026. Its developer notes include a small but useful change for data teams: the built-in JSON Viewer now opens JSON Lines and NDJSON documents served with common JSON Lines media types or a .jsonl extension.

That matters to proxy-backed collection workflows because many useful operational records are naturally append-only. One line can represent one request, one proxy exit, one retry, one parsing result or one validation decision. Inspecting those records directly in a browser does not replace automated validation, but it shortens the path from a failed job to the exact event that needs investigation.

Public source note: Mozilla MDN, “Firefox 155 release notes for developers,” released September 1, 2026.

What changed in Firefox 155

Firefox's JSON Viewer previously focused on conventional JSON documents. Firefox 155 expands that surface to JSON Lines documents delivered as application/jsonlines, application/x-ndjson, text/jsonl, or with a .jsonl filename.

NDJSON stores one valid JSON value per line. Unlike a single large JSON array, an append-only stream can be written and processed incrementally. If a collection worker stops after line 8,500, the earlier complete lines can still be examined without closing one giant array.

The browser feature is an inspection convenience. It does not certify that every line follows your schema, that no record is missing, or that sensitive values were removed. Those remain pipeline responsibilities.

Why proxy teams should care

A generic success counter cannot explain whether a bad result came from a proxy, a target response, a retry policy or a parser. A compact line record can preserve the evidence needed to separate those layers.

For each authorized request, record fields such as:

Use stable field names and explicit null values. Do not overload one field with several meanings or infer missing values from line order.

Design one event per line

The most useful unit is an event with a clear boundary. A line should be independently parseable and small enough to inspect, filter and transmit safely.

A practical event model separates:

1. request intent: market, protocol, session mode and authorized target label;
2. route observation: gateway, address family and sanitized exit identity;
3. response evidence: status, content type, byte count and timing;
4. processing result: parser version, schema result and accepted-record count;
5. control decision: retry, rotate, back off, quarantine or stop.

Do not store a raw proxy URL. It may contain a username, password, gateway host and targeting parameters. Keep secrets in an approved secret manager and write only a non-sensitive configuration label to the event.

Add integrity controls before using the browser

Browser viewing is the last mile of diagnosis, not the first line of defense. Generate and validate the stream with deterministic controls:

• a schema version on every line;
• a unique event ID and parent operation ID;
• monotonically increasing sequence numbers within each worker stream;
• explicit start and completion records for each job;
• a checksum for exported diagnostic bundles;
• a final count of attempted, successful, rejected and retried events;
• a validator that reports the first invalid line and all missing required fields.

If multiple workers append to one file, do not assume physical line order represents causal order. Use timestamps, operation IDs and sequence numbers.

Use Firefox 155 for a bounded inspection pass

When a proxy-backed job fails, use a sanitized diagnostic copy:

1. confirm the file uses an expected JSON Lines media type or .jsonl extension;
2. open the copy in Firefox 155 or later;
3. locate the first failed validation or transport event;
4. follow its parent operation and session hash;
5. compare the previous attempt, route decision and next retry;
6. check whether the exit, address family or gateway changed;
7. confirm that the final accepted-record count matches downstream storage;
8. record the incident cause without copying secrets into a ticket.

For a complex network incident, pair this with the proxy bypass audit and the proxy concurrency ramp test.

Detect common proxy data failures

Retry inflation

Group lines by operation ID and count attempts. A job can report 10,000 completed operations while consuming 25,000 proxy requests. Record both the final result and every attempt so bandwidth and target load remain visible.

Session drift

Within a sticky session, compare the route and exit fields across sequential events. An expected rotation and an accidental session change require different fixes.

Partial output

Require a completion record and compare its counts with the number of accepted events. A syntactically valid file may still end early after a worker crash.

Parser regression

Store parser and schema versions. If HTTP success remains stable while validation failures jump after a deployment, the proxy may be healthy and the parser may be wrong.

Mixed address families

Record IPv4 and IPv6 explicitly. Otherwise, a dual-stack difference can look like random geolocation or latency variation.

Set a release gate

Before promoting an NDJSON logging change, require:

• every line parses independently;
• required fields are present for every event type;
• secret scanners find no proxy credentials, cookies, tokens or personal payloads;
• job start, completion and count reconciliation pass;
• retry attempts and route changes remain visible;
• truncated and malformed test fixtures fail predictably;
• a large sample opens for manual inspection without becoming the only validation method;
• retention, access and deletion rules are documented.

Use pass, conditional pass, fail and inconclusive. A file that opens in Firefox but fails reconciliation is not a pass.

Operations checklist

• Upgrade a test profile to Firefox 155 or later.
• Serve diagnostic copies with a recognized JSON Lines media type.
• Keep one independently parseable event per line.
• Add schema, operation, event and sequence identifiers.
• Record retry attempts instead of only final success.
• Label gateways and sessions without writing credentials.
• Separate route, response, parsing and business validation fields.
• Reconcile job totals against downstream accepted records.
• Scan every export for secrets before sharing.
• Apply access controls and a deletion date to diagnostics.

FAQ

Does Firefox 155 validate an NDJSON schema?

No. It makes supported JSON Lines documents easier to view. Schema validation, required-field checks and reconciliation must run in your pipeline.

Should one line represent one page?

Not always. One request can produce several parsed records, and one page can require several requests. Use one clearly defined event per line and connect related events with an operation ID.

Can NDJSON contain raw proxy credentials for reproduction?

It should not. Store a safe configuration label and retrieve secrets only from an approved secret manager during an authorized reproduction.

Is a final success line enough?

No. Preserve attempt-level evidence so retries, route changes, cost and partial failures remain measurable.

Compliance note

Collect and inspect only data you are authorized to access. Follow destination terms, provider contracts, privacy requirements and rate limits. Do not place authentication secrets, personal payloads or unrestricted target URLs in diagnostic streams. Use proxies for legitimate testing and data operations, not to evade access controls, conceal abuse or create artificial traffic.