elijahsawyers

Summary

Works in WebKit's WebExtensions layer, concentrated on the network-facing extension APIs — webRequest event delivery for `tabs.create`-initiated loads and for loads blocked by declarativeNetRequest — plus manifest.json parse tolerance affecting whether an extension loads in Safari at all. No security or hardening work appears in the recent record; the pattern is API-correctness plumbing in the extension surface rather than memory safety or mitigation work. Where to look next: the webRequest/declarativeNetRequest intersection, since changes to which loads emit events directly change what an installed extension can observe about blocked traffic.

Components

Security Fix History

• 2026-09-18 Add the notification delegate API surface for the browser.notifications web extension API 2026-W37
• 2026-09-02 Fire webRequest events for declarativeNetRequest-blocked loads 2026-W35

Hardening Commits

• No hardening commits recorded

Recent Commits

• 2026-09-18 Add the notification delegate API surface for the browser.notifications web extension API 2026-W37
• 2026-09-17 Add a feature flag for the browser.notifications web extension API
• 2026-09-16 webRequest events never fire for subframes loaded inside an action popup
• 2026-09-14 webRequest reports the wrong parentFrameId for a first-level subframe
• 2026-09-14 webRequest main_frame and sub_frame type filters are swapped
• 2026-09-14 webRequest reports main_frame instead of sub_frame for subframe document loads
• 2026-09-11 i18n.getMessage() drops non-string substitution arguments instead of coercing them to strings
• 2026-09-09 DNR high priority static redirect rule not favored over low priority session redirect rule
• 2026-09-03 webRequest events not firing with tabs.create
• 2026-09-02 Fire webRequest events for declarativeNetRequest-blocked loads 2026-W35
• 2026-03-09 Extensions with a trailing common in manifest.json don't show in Safari