[Workers] Document two event spec compliance compatibility flags

[rexxars]

Summary

Documents two new compatibility flags added to the Workers runtime in cloudflare/workerd#7019. Both fix places where our event classes deviate from the DOM and HTML standards.

• spec_compliant_event_handler_attributes: on<type> handlers, such as WebSocket.onmessage and AbortSignal.onabort, fire in the order they were assigned rather than ahead of every listener, and fire once rather than twice for a class that implements them by registering a listener. Fixes EventTarget is broken and not aligned with spec workerd#6022.
• spec_compliant_message_event_origin: MessageEvent.origin reports an empty string rather than null when there is no origin, and a WebSocket opened from a URL reports the origin of that URL.

Each page covers what changes, a before and after example, and the disable flag.

Neither has an enable_date yet, so both pages omit that field and use the date they were written as sort_date. The flags are opt-in until the runtime PR settles on dates, and I will update this PR with them at the same time as the flag definitions. This goes up alongside the runtime change because docs/api-updates.md in workerd asks for the documentation to land before the enable date.

The runtime PR carries a third fix, making isTrusted false on events constructed in JavaScript, which has no compatibility flag after review feedback that it did not need one. There is no page for it here, since these pages document flags.

No changelog entry for the two flags, since nothing changes for an existing Worker until they have enable dates. The isTrusted fix does take effect when the runtime PR merges, so tell me if you would like a changelog entry for that one and I will add it.

Documentation checklist

• The change adheres to the documentation style guide.

[cloudflare-docs-bot]

Review

⚠️ 1 warning found in commit adaf92b.

👉 Fix in your agent 👈

Fix the following review findings in PR #32777 (https://github.com/cloudflare/cloudflare-docs/pull/32777).

Before making changes, review each finding and present a brief summary table:
- For each finding, state whether you agree, disagree, or need clarification
- If you disagree (e.g. the fix requires disproportionate effort for minimal benefit,
  or the finding is factually incorrect), explain why
- If you need clarification before deciding, ask those questions
- Then share your plan for which issues to tackle and in what order

After triaging, follow this order:
1. Post a comment on this PR for any findings you are skipping, with the finding ID and your reasoning.
2. Then commit the fixes for the legitimate findings.

The comment must come before the commit — the bot reads PR comments when a new
push triggers a review, so skip comments posted after the push will be missed.

---

## Conventions

### Warnings (1)

#### CV-ef3b8a5ba845 · Scope accuracy
- **File:** PR-level finding
- **Issue:** The PR description lists three compatibility flags and says "Each page covers...", implying three new pages, but `args.changedFiles` only shows two new files (`spec-compliant-event-handler-attributes.md` and `spec-compliant-message-event-origin.md`). The third flag, `spec_compliant_event_is_trusted`, has no corresponding changed file.
- **Fix:** Add the missing `spec-compliant-event-is-trusted.md` page, or update the description to clearly state which flags are actually included in this PR.

Code Review

This code review is in beta and may not always be helpful — use your judgment.

_{No code review issues found.}

Conventions

Warnings (1)

File

Issue

PR

Scope accuracy — The PR description lists three compatibility flags and says "Each page covers...", implying three new pages, but args.changedFiles only shows two new files (spec-compliant-event-handler-attributes.md and spec-compliant-message-event-origin.md). The third flag, spec_compliant_event_is_trusted, has no corresponding changed file. Fix: Add the missing spec-compliant-event-is-trusted.md page, or update the description to clearly state which flags are actually included in this PR.

Style Guide Review

_{No style-guide issues found.}

Commands

Only codeowners can run commands. Post a comment with the command to trigger it.

Command	Description
/review	Runs a review now. Incremental if a prior review exists, full if not.
/full-review	Re-reviews the entire PR diff from scratch, ignoring incremental history. Useful after a rebase, when you want a fresh review, or if the bot gets out of sync and reports issues that no longer exist.
/ignore-review-limit	Permanently lifts the 2-review automatic limit for this PR. Future pushes will trigger reviews as normal.
/disable-auto-review	Stops automatic reviews from triggering on future pushes to this PR. Codeowners can still run /review or /full-review manually.
/rebase	Rebases the PR branch against production. On conflict, attempts to resolve automatically using AI. Stops with an explanation if confidence is not high enough.

[rexxars]

CR-1127b6e4aab4 (Incorrect addEventListener return-value behavior)

Disagree on the factual claim, but rewording anyway, because the sentence is ambiguous enough that a reader could reach the same conclusion.

The claim is that return-true-cancels "applies only to the old on<type> dispatch path, not to addEventListener() listeners." In the Workers runtime it applies to both, and always has:

• There is no separate dispatch path for on<type>. In EventTarget::dispatchEventImpl() (src/workerd/api/basics.c++), the rule is applied to every JavaScript handler in the callbacks vector, and that vector is built from the handler table addEventListener() writes to. The legacy on<type> property lookup contributes one additional entry to the same vector.
• This predates Fix event handler attributes workerd#7019. On main, if (handle->IsTrue()) event->preventDefault(); sits in the single JavaScriptHandler case of that loop, under the comment "Returning true is the same as calling preventDefault() on the event."
• Destination IP Selector does not exist #7019 adds a test for it. listenerReturningTrueStillCancels registers a listener with addEventListener() that returns true, dispatches a cancelable event, and asserts dispatchEvent() returns false and defaultPrevented is true. It passes with the flag both enabled and disabled.

The DOM standard part of the finding is correct: a listener's return value is ignored, and never cancels. That is exactly why #7019 leaves addEventListener() listeners alone and changes only on<type> handlers. There is no standard behavior to move listeners to, so changing them would be a much wider break with nothing to align to.

So the docs sentence was describing the runtime's rule, not the standard's. Rewording it to say that outright, since "which is the rule the Workers runtime applies" reads as a claim about expected behavior:

Without this flag, returning true cancels the event and false is ignored. That is not standard behavior. The DOM standard ignores the return value of a listener added with addEventListener() entirely, and the Workers runtime applies its own true cancels rule to those listeners as well. This flag changes only on<type> handlers, so listeners added with addEventListener() keep the existing behavior.

Pushing that now.