Team IT Security - 💾 Tools

v15.10.7

Tue, 09 Jun 2026 00:32:37 +0200

chore: bump version to 15.10.7

v15.10.6

Mon, 08 Jun 2026 22:39:20 +0200

chore: bump version to 15.10.6

Firefox Tooling Announcements: MozPhab 2.15.2 Released

Mon, 08 Jun 2026 20:41:50 +0200

Bugs resolved in Moz-Phab 2.15.2: bug 2004368 moz-phab patch -a here with jj says there is no source tree if jj config is broken bug 2035900 Investigate setting up CodSpeed.io for moz-phab bug 2044857 patch --raw leaks a global logger level, causing order-dependent test failures Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix. 1 post - 1 participant Read full topic

v15.10.5

Mon, 08 Jun 2026 19:11:24 +0200

chore: bump version to 15.10.5

Make Firefox your World Cup sidekick this summer

Mon, 08 Jun 2026 17:59:22 +0200

Your browser tabs say a lot about your life: work projects, vacation plans, shopping carts and all the rabbit holes in between. Add the world’s biggest soccer tournament to the mix, and your browser is suddenly juggling scores to check, streams to watch, lineups to scan and group chats to keep up with. And since […] The post Make Firefox your World Cup sidekick this summer appeared first on The Mozilla Blog.

v15.10.4

Mon, 08 Jun 2026 12:27:26 +0200

chore: bump version to 15.10.4

v15.10.3

Mon, 08 Jun 2026 07:17:08 +0200

test(coding-agent): realigned stale tests with intentional behavior c…

v15.10.2

Mon, 08 Jun 2026 02:57:31 +0200

chore: bump version to 15.10.2

v15.9.0

Thu, 04 Jun 2026 06:26:00 +0200

@oh-my-pi/pi-ai Fixed Fixed MiniMax-compatible OpenAI-completions hosts (e.g. minimax-code-cn/MiniMax-M3) losing tool-call arguments when the stream delivers function.arguments as a complete object instead of the OpenAI JSON-string contract. The streaming buffer previously concatenated the object into a string, coercing it to [object Object] and leaving bash/edit calls with empty or malformed inputs; the tool-call block now holds the object payload directly. (#1776) Fixed Cloud Code Assist (Gemini / Antigravity) rejecting tool schemas with Invalid JSON payload received. Unknown name "propertyNames" (HTTP 400) when a tool exposed a property literally named properties (e.g. the Resend MCP create_contact tool). The schema normalizer's insideProperties flag was re-asserted when descending into such a property's value schema, so Google-unsupported keywords (propertyNames, additionalProperties, …) nested inside it were never stripped. The flag is now only set when entering a real properties map from a schema node, not from within another properties map. Fixed local/self-hosted providers leaking machine-specific endpoints into the bundled models.json. A generate-models run on a machine with a LiteLLM proxy baked 1202 litellm models pinned to http://localhost:4000/v1 into the committed catalog. litellm (and lm-studio) now join ollama/vllm in the generator's discovery-only exclusion set, so local providers are never fetched during generation nor written to models.json — they are discovered dynamically at runtime instead. LiteLLM model discovery now enriches metadata against models.dev (the same reference source the other gateway providers use) rather than a bundled reference map. Added a regression test pinning the invariant (no local provider blocks, no loopback/private-network baseUrls in the bundled catalog). @oh-my-pi/pi-coding-agent Breaking Changes Removed synchronous readTextSync from SessionStorage and core implementations (MemorySessionStorage, FileSessionStorage, RedisSessionStorage, SqlSessionStorage), requiring callers to use async text reads Replaced the public SessionStorage readTextPrefix(path, maxBytes) and readTextSuffix(path, maxBytes) methods with readTextSlices(path, prefixBytes, suffixBytes): Promise; custom session storage backends must implement the new combined slice API. Added Added env-driven OpenTelemetry trace export. When OTEL_EXPORTER_OTLP_ENDPOINT (or OTEL_EXPORTER_OTLP_TRACES_ENDPOINT) is set, omp registers a global OTLP/proto trace exporter and switches on the agent loop's telemetry, so the invoke_agent / chat / execute_tool spans actually reach a collector instead of a no-op tracer. Honors the standard OTEL_* env contract (endpoint, headers, OTEL_SERVICE_NAME, OTEL_SDK_DISABLED and OTEL_TRACES_EXPORTER=none parsed case-insensitively) and the OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT capture toggle; it is a no-op when no endpoint is configured. Only the http/protobuf transport is supported — a grpc or http/json OTEL_EXPORTER_OTLP*_PROTOCOL declines rather than misrouting spans. This makes the existing telemetry usable from headless hosts that run omp as a spawned child process, where an in-process TracerProvider registered by the parent can't reach the child. Uses the @opentelemetry/exporter-trace-otlp-proto 2.x line, which exports cleanly under Bun. Fixed Fixed the status line session name (and the editor border / status-line gap fill) being nearly illegible on light themes. Added IndexedSessionStorage and SessionStorageBackend exports to support shared metadata-indexed session backends Added the tui.maxInlineImages setting (default 8) capping how many inline images render as live terminal graphics. Once a new image pushes the count past the cap, the oldest images are hidden via a full redraw — replaced by their [Image: …] text placeholder and purged from the terminal's graphics store — so long sessions with many screenshots/diagrams stop piling up images (and, on Kitty, stop leaving scrollback ghosts). Set to 0 to keep every image inline. Added a "View: terminal state" item to the /debug menu that prints the detected terminal, live geometry and cell size, multiplexer, and the negotiated subprotocols actually in use — graphics (Kitty/iTerm2/Sixel), desktop notifications (BEL/OSC 9/OSC 99, plus whether OSC 99 was confirmed via a device-attributes probe), OSC 8 hyperlinks, 24-bit color, DECCARA rectangular-SGR background fills, and DEC 2026 synchronized output — alongside the scrollback-clear strategy (CSI 22 J vs CSI 2 J redraw / ED3 eager-erase risk) and the raw TERM/TERM_PROGRAM/COLORTERM detection signals. Added a "Test: terminal protocols" item to the /debug menu that renders one live sample of every special escape protocol the renderer can emit — SGR text attributes (bold/italic/underline/strikethrough/inverse/dim), themed and 24-bit truecolor, OSC 8 hyperlinks, OSC 66 text sizing (large text), and an inline graphics swatch via the active image protocol (Kitty/iTerm2/Sixel, with a text fallback) — and fires a desktop notification, so you can eyeball which protocols the current terminal actually honors. The sample image is a gradient PNG generated in-process, so the graphics test needs no asset on disk. Added the tui.textSizing setting (default off) that renders Markdown H1 headings at 2x scale via Kitty's OSC 66 text-sizing protocol. It replaces the undocumented PI_TUI_TEXT_SIZING env var with a real setting, and only takes effect on Kitty terminals (where OSC 66 is implemented) — it is ignored everywhere else so headings never emit raw escape bytes. Added a lifecycle status to the /resume session picker. Each session's tail (last 32 KiB) is now read alongside the existing header window in a single pass, and its final message classified as done (the agent ended its turn and yielded control back), interrupted (a trailing tool call or tool result the loop never continued from), aborted, error, or pending (a trailing user message with no reply). The status renders as a colored segment on each session's metadata line. When the final message is larger than the tail window the status is omitted rather than guessed. Added support for disable-model-invocation: true frontmatter field from the Agent Skills standard. Skills using this field are now hidden from the system prompt listing, matching the behavior of hide: true. Changed Changed the task tool description to tag read-only agents and explicitly forbid assigning them file edits/commands or offloading reasoning to quick_task/explore. Changed Redis and SQL session storage initialization to load only indexed metadata (size, mtimeMs) instead of full session content Changed SessionStorage read paths to rely on backend-backed metadata/indexed storage, so session content is fetched on demand rather than cached as full in-memory mirrors Changed session-list slice reads to go through SessionStorage.readTextSlices across all backends, removing the file-only single-open branch and caller-managed buffers. FileSessionStorage now reads both windows via peekFileEnds, while Redis and SQL backends encode session content once per combined read. Changed the ask tool transcript renderer to mark single-choice questions with circular radio glyphs (○/◉) instead of the rectangular checkbox glyphs (☐/☑) it shares with multi-select questions, so a "pick one" combo box visually reads as a radio group rather than a checklist. Multi-select questions keep checkboxes. Added a radio.selected/radio.unselected symbol pair across the unicode, nerd-font, and ASCII presets. Changed the ask tool transcript renderer to mark the chosen answer inside the question form rather than re-listing the questions in a detached summary block below it. Once a question is answered, the standalone prompt preview is dropped and the result redraws the same form — every offered option still shown, with the selected one(s) filled in (◉/☑, highlighted) and the rest dimmed (○/☐); custom free-text answers and cancellations render in place as the final entry. This removes the duplicate question/option listing that previously appeared once as the call preview and again as the result. Changed task-completion and ask desktop notifications to structured terminal notifications (title, body, type, and a focus-on-click action). On Kitty these render through OSC 99 as a proper title/body with click-to-focus; terminals without confirmed OSC 99 support collapse them to the previous single-line message (BEL/OSC 9). Updated the "each kitty/tmux split" tip to include cmux. Fixed Fixed tiny-model startup in compiled binaries by resolving @huggingface/transformers and its runtime dependencies from the installed cache using package.json exports/main metadata, preventing module-resolution failures when launching models Fixed tiny runtime installation flow in compiled binaries by using the build-time resolved @huggingface/transformers version and ensuring the runtime lock directory’s parent exists before acquiring the install lock, preventing mismatch and setup failures on fresh installs Fixed the terminal protocol debug probe reusing one stable Kitty graphics id across repeated panels, which could move/replace an earlier swatch instead of rendering a new one. Fixed selector dialogs (the ask tool, hook prompts) collapsing to a single visible option on shorter terminals when options carried long descriptions: the highlighted option's wrapped description consumed the entire row budget, hiding every other option and making the menu feel unnavigable (down moved the lone visible entry, left/right did nothing). When the fully-expanded list overflows, HookSelectorComponent now renders a compact list — every option label stays on screen and only the highlighted option expands its description, truncated to the remaining rows — so the whole menu is always visible and the detail pane follows the cursor. Fixed read failing with "Path not found" on web URLs whose scheme // collapsed to a single / (e.g. https:/github.com/...), which happens when a URL is routed through Node's path.normalize/path.resolve. The fetch URL recognizer now accepts a single-slash scheme and repairs it back to // before fetching, so collapsed URLs resolve instead of falling through to filesystem lookup. Fixed subagent slow-model priority falling through to older Claude Opus aliases when Opus 4.8 is available by adding Opus 4.8 and 4.7 aliases ahead of older Opus fallbacks (#1753). Fixed the web-search provider selectors in TUI settings/setup to derive from the shared provider metadata, so newly added providers cannot be omitted from the preference list. @oh-my-pi/pi-natives Fixed Bounded sorted glob() scans to maxResults during uncached traversal and emitted onMatch callbacks only for entries admitted to the bounded top-maxResults heap so broad OMP find progress and timeout partials stay consistent with the returned mtime-ranked set while keeping parent-process memory bounded (#1761). Fixed wrapTextWithAnsi hanging (infinite loop) on text containing a BEL-terminated string escape — DCS/SOS/PM/APC (ESC P/ESC X/ESC ^/ESC _) closed by BEL instead of ST. ansi_seq_len_u16 only accepted the ST (ESC \) terminator for these (OSC already accepted both), so a BEL-terminated APC such as the TUI cursor marker (ESC _ pi:c BEL) was left unclassified: it was miscounted as visible width and break_long_word's non-ESC scan could not advance past the ESC, spinning forever. The terminator set now matches OSC (ST or BEL), and break_long_word defensively emits and steps over any escape it cannot classify so a malformed/unknown sequence can never wedge the wrap loop. @oh-my-pi/swarm-extension Fixed Fixed swarm /swarm run failing with authStorage/modelRegistry identity error (#1472) @oh-my-pi/pi-tui Added Added Kitty CSI 22 J screen-to-scrollback clears for non-destructive full paints, while keeping ED3 for destructive history/session rebuilds. Added Kitty OSC 99 rich notification formatting and startup capability probing. Added Kitty OSC 66 text-sized Markdown H1 headings (2x scale) plus native text-width support for OSC 66 spans. Off by default and gated to Kitty (the only terminal implementing OSC 66) via the TERMINAL.textSizing capability; hosts enable it through setTextSizing. Added Kitty Unicode placeholder image rendering (U=1 + U+10EEEE with explicit row/column diacritics): inline images are drawn as real text cells that carry the image id in their foreground color, so they survive horizontal slicing, reflow, and overlapping draws instead of relying on cursor-positioned a=p placements. Enabled by default on Kitty-family terminals; opt out with PI_NO_KITTY_PLACEHOLDERS=1, and falls back to direct placement when a grid exceeds the diacritic table's addressable range. Added Kitty temp-file image transmission (t=t): on local sessions, decoded PNG bytes are written to a tty-graphics-protocol temp file and the path is sent instead of in-band base64, gated behind a startup a=q,t=t support probe. Controlled by PI_KITTY_IMAGE_TRANSMISSION=direct|temp-file|auto; disabled over SSH unless explicitly forced. Added DECRQM capability detection for DEC private modes 2026 (synchronized output) and 2048 (in-band resize). Synchronized-output paint wrappers are dropped when the terminal reports 2026 unsupported (preserving the PI_NO_SYNC_OUTPUT override), and DEC 2048 in-band resize is enabled when supported — reported geometry and cell pixel size are updated from CSI 48 ; rows ; cols ; yPx ; xPx t reports, with SIGWINCH and CSI 16 t kept as fallbacks. Added an injectable render scheduler for TUI tests, allowing deterministic render drains without patching global clocks or event-loop timing. Added ImageBudget, an inline-image cap that keeps only the most recent N images as live terminal graphics and demotes older ones to their text fallback. Once a new image pushes the count past the cap, the renderer hides the oldest via a full redraw plus an explicit Kitty graphics purge (a=d,d=I) — text-clear escapes (CSI 2 J/CSI 3 J) do not remove Kitty images. Configure the cap via TUI#setMaxInlineImages (0 disables it). Changed Kitty inline images to a transmit-once + placement scheme: the base64 data is sent a single time (a=t) keyed by a stable image id, then every repaint emits only the tiny placement (a=p,i=…,p=…). Repaints — including full redraws — no longer re-send image data or stack duplicate placements, and the diff/line buffers and render caches hold short placement strings instead of multi-KB base64. The ImageBudget doubles as the transmit store (it tracks which ids are loaded and re-transmits after a purge frees the data). iTerm2/Sixel, which have no addressable image store, keep sending inline data as before. Added a renderer-level DECCARA rectangular-SGR optimizer that paints solid background panels/rows (Box/Text/Markdown fills, status bars, any full-width theme.bg row) as a single coalesced rectangle escape (CSI 2*x / CSI Pt;Pl;Pb;Pr;$r / CSI *x) instead of emitting a full-width run of background-styled spaces on every visible row. It operates at emit time on the final ANSI strings — components are unchanged — and strips only trailing padding it can prove sits under a single non-default background span, coalescing vertically adjacent identical fills into one rectangle and falling back to the original bytes whenever the rectangle would not save bytes. Enabled only on Kitty, which implements the SGR-background extension (docs/deccara.rst); Ghostty is intentionally excluded because its CSI $r is unimplemented (ghostty-org/ghostty#632) and would drop the background entirely. Scrollback-bound rows and the append/scroll paths always keep the padded representation so native history preserves colored cells, and the PI_NO_DECCARA kill switch (plus tmux/screen/zellij detection) forces the fallback. Added CMUX_SURFACE_ID environment variable support to getTerminalId(), so cmux terminal surfaces get a stable identifier alongside kitty, tmux, macOS Terminal.app, and Windows Terminal — enabling per-surface session breadcrumbs for omp -c in cmux. Changed Changed TUI tests to use Ghostty's VT engine (ghostty-web) instead of @xterm/headless. Changed the default inline-image live graphics budget from 3 to 8 images. Fixed Fixed the DECCARA background-fill optimizer rejecting or repainting the wrong cells when a trailing fill crossed from default-background spaces into colored spaces. Fixed DEC private-mode reports with DECRPM status 3/4 being treated as unsupported, so permanent 2026/2048 reports stay recognized. Fixed OSC 66 text-sizing width and slicing edge cases, including ZWJ emoji payloads and partial slices through scaled spans. Fixed focused Input components following TUI#setShowHardwareCursor, so single-line prompts render either the terminal cursor or software cursor consistently with the editor. Fixed the DECCARA background-fill optimizer painting fills on the wrong rows ("split into unaligned halves") in the differential repaint path. When a diff grew the transcript past the viewport, writing the rewritten rows scrolled the terminal, but the absolute DECCARA rectangle coordinates were derived from the pre-scroll viewport top, so every fill landed scrollAmount rows too low while the relatively-positioned text settled correctly; rows scrolled into history were also shortened, dropping their background padding from native scrollback. Rectangles now target the post-scroll rows and only rows remaining in the final viewport are optimized. Fixed native scrollback desynchronization after terminal width or height changes reflowed overflowing content while the viewport was not at the bottom Fixed a notification chip (or any injected block) rendering on top of an actively streaming tool render on ED3-risk terminals (Ghostty/kitty/Alacritty/iTerm2). While a foreground tool streams, its header's elapsed-time counter ticks every frame; once output scrolls the header above the viewport top, each tick is an offscreen edit that — because the eager scrollback-rebuild opt-in is gated off on these terminals — repaints the viewport in place and advances the rendered line count without committing the new overflow to native history. #scrollbackHighWater then lagged the logical viewport top, so a later content shrink whose changes landed in the visible region slipped past the shrink-across-boundary guard and reached the differential emitter, which is anchored to #maxLinesRendered - height: it rewrote only the suffix, dropped the newly exposed top row, and left a blank at the bottom, drifting every row below the edit one line up so it painted over the rows above. Such shrinks now re-anchor the bottom of the viewport with a non-destructive repaint, and the foreground-streaming shrink-across-boundary case repaints the live tail instead of padding and pinning the pre-shrink viewport. Fixed a terminal resize during foreground-tool streaming on an unknown-viewport / ED3-risk host (Ghostty/kitty/Alacritty/iTerm2/WSL) leaving native scrollback permanently out of sync, so scrolling back after the turn showed missing rows. A pure geometry resize (no content change) takes the in-place viewport-repaint path, which — unlike a content-bearing resize that rebuilds via the geometry branch — never flagged native history. Because the prompt-submit checkpoint (refreshNativeScrollbackIfDirty) only rebuilds when scrollback is marked dirty on these hosts, the discrepancy was never reconciled. Overflowing geometry repaints whose viewport is not known to be at the bottom now mark scrollback dirty so the next checkpoint rebuilds an exact copy of the transcript. @oh-my-pi/pi-utils Added Added color helpers colorLuma (perceptual luma), relativeLuminance (WCAG, linearized sRGB), and hslToHex to the color utilities. The luminance helpers parse #rgb/#rrggbb hex and 256-color palette indices, returning undefined for unparseable values. Added peekFileEnds, a single-open head-and-tail file peek helper that reuses the head bytes for the tail when the file fits the head window. Added peekFileTail, the tail mirror of peekFile: reads up to the last maxBytes of a file ending at EOF, reusing the same pooled-buffer strategy (no per-call allocation for small reads). What's Changed fix(search): default paths to workspace root instead of hard-failing by @GratefulDave in #1808 fix: recognize disable-model-invocation from Agent Skills spec by @fabkho in #1803 fix(coding-agent/mcp): handle async broken-pipe rejections in stdio transport by @VoidChecksum in #1783 Fix slow agent Opus priority by @daandden in #1754 fix(swarm): remove redundant authStorage discovery from swarm pipeline (#1472) by @WodenJay in #1726 Fix web search provider TUI options by @daandden in #1685 Add cmux terminal surface detection to getTerminalId by @basedcorp99 in #1702 fix(natives): bound sorted glob scans by @roboomp in #1762 fix(tui): cap session accent luminance on light themes by @paweljw in #1715 feat(coding-agent): env-driven OTLP trace export for headless hosts by @cgreeno in #1797 New Contributors @GratefulDave made their first contribution in #1808 @fabkho made their first contribution in #1803 @WodenJay made their first contribution in #1726 @paweljw made their first contribution in #1715 @cgreeno made their first contribution in #1797 Full Changelog: v15.8.3...v15.9.0

v15.9.1

Thu, 04 Jun 2026 19:03:15 +0200

@oh-my-pi/pi-ai Added Added regional Xiaomi Token Plan login/provider entries (xiaomi-token-plan-sgp, xiaomi-token-plan-ams, xiaomi-token-plan-cn) so omp login can store token-plan keys against the selected region. (#1846) Fixed Removed the context-1m-2025-08-07 (1M long-context) beta from the Anthropic agent request headers, the OAuth model-discovery header, and the Claude usage-API header. Sending it caused subscription/OAuth requests without long-context credits to fail with 429 Usage credits are required for long context requests, breaking Sonnet. The remaining betas are unchanged. Fixed Kimi K2.x maxTokens on Fireworks and Fire Pass (fireworks/kimi-k2.5, fireworks/kimi-k2.6, firepass/kimi-k2.6-turbo) being inherited from Fireworks /v1/models discovery (max_completion_tokens: 65536) rather than the published Kimi-on-Fireworks output budget, which let callers (and the openai-completions default-injection safety net) ship a budget the router cannot honor and made runaway reasoning traces more likely. The Fireworks resolver now clamps every Kimi K2.x id (public catalog ids and the canonical accounts/fireworks/{models,routers}/kimi-k2… wire form) to 32,768 output tokens, and the generator applies the same cap as a post-processing safety net so the firepass static fallback and the bundled fireworks entries stay in sync across regens. (#1849) Fixed Xiaomi Token Plan MiMo OpenAI-compatible tool-call continuations omitting required reasoning_content replay. (#1846) Fixed Anthropic prompt caching for OpenAI-compatible Claude proxies by honoring compat.cacheControlFormat: "anthropic" outside OpenRouter. (#1845) Fixed Moonshot Kimi K2.6 silently pausing for many seconds between tool calls because the server discarded the reasoning_content that omp was already sending with every assistant tool-call replay. The K2.6 thinking parameter takes an extra keep field whose default (null) ignores historical reasoning, so K2.6 had to re-derive its full chain-of-thought from the user prompt on every iteration of the agent loop. The Moonshot direct (api.moonshot.ai) and Kimi Code (api.kimi.com) wire bodies now send thinking: { type: "enabled", keep: "all" } for kimi-k2.6 requests with reasoning enabled, matching Moonshot's documented best practice for multi-step tool-calling agents. The flag is gated on the K2.6 id and the two native hosts because earlier Moonshot models (K2.5 and below) 400 on the unknown field and every Kimi gateway (OpenRouter, OpenCode, Kilo, Fireworks, …) speaks its own thinking shape. (#1838) Fixed Alibaba DashScope (Bailian) compatible-mode endpoint 400 InternalError.Algo.InvalidParameter: The provided messages input is invalid. The error info is [Unexpected item type in content.] when a screenshot or other image-producing tool result was folded into a known text-only Qwen turn (e.g. qwen3.7-max, qwen-max, qwen3-coder-*) hosted at dashscope.aliyuncs.com/compatible-mode/v1. convertMessages in openai-completions no longer forwards image_url content parts for those text-only id families even when a misconfigured custom provider claims input: ["text", "image"]; multimodal compatible-mode ids such as qwen3.7-plus and qwen-vl-max still rely on the catalog input field. The tool-result branch and the user-content branch both fall back to the standard [image omitted: model does not support vision] placeholder for text-only ids so the model still sees the attachment intent. (#1859) @oh-my-pi/pi-coding-agent Added Added deferred session-title generation so greetings no longer become the session title. A first user message that is only a greeting / acknowledgement / filler ("hi", "thanks", "ok", a bare number, emoji-only, etc.) is now detected deterministically and skips titling entirely — no title model is invoked. Title generation then retries on each subsequent user message while the session stays unnamed, so the title is deduced from the first message that actually describes work. A capable online title model may additionally answer none to decline a non-greeting taskless message (normalized to "no title"). Changed Changed mid-turn user steers to reach the model inside a wire-only interjection envelope, while transcripts and persisted session history keep the user's original text. Changed the system prompt to treat user requests for parallel work as task subagent fan-out rather than parallel tool calls. Changed the Agent Control Center's new-agent description field to use the multiline TUI editor, with Enter inserting lines and Ctrl+Enter generating the spec. Changed the Agent Control Center and Extension Control Center to accept Left/Right arrow keys for switching tabs (source / provider), in addition to Tab / Shift+Tab — matching the model and settings selectors, whose TabBar already supported arrow navigation. Refreshed the Ctrl+R history search overlay: the selected row now renders as a full-width selectedBg highlight bar, matched query tokens are highlighted in the accent color, each result shows a right-aligned relative timestamp, and the panel gained an icon'd accent title plus a two-tone keyhint footer. The selector also gained PageUp/PageDown (via the configurable tui.select.pageUp/pageDown keybindings) and Home/End navigation. Changed Perplexity API-key web search to return more comprehensive results: web_search_options.search_context_size is now high (was medium) for maximum retrieval grounding, the default num_search_results is 20 (was 10) so twice as many sources are surfaced, and return_related_questions is enabled with the response's related_questions now parsed into relatedQuestions (previously dropped). On an identical query this lifted the result from 10 sources / ~410 output tokens to 20 sources / ~1900 output tokens with a structured, multi-section answer; latency tracks model output length, not context size, so the 60s hard timeout headroom is unchanged. Fixed Fixed a streamed assistant message freezing at a partial prefix (e.g. only "Nat" of "Natives built, now…") on ED3-risk terminals (Ghostty/kitty/iTerm2/Alacritty), with the final text appearing only after a resize. TranscriptContainer freezes each non-live block by replaying its last live render, but render coalescing can finalize a block's content and append the next block within the same throttled frame — so the block was sealed at its stale mid-stream snapshot and never repainted until the next thaw. The block that was live on the previous render is now recomputed once on the live→frozen transition, sealing it at its final content. Fixed ACP/RPC stdio startup so protocol frames are no longer consumed as one-shot piped prompt input before the JSON-RPC transport starts. Fixed omp completions to await the completion script write before exiting. Fixed AssistantMessageComponent exposing its stable-prefix completion API again so streamed assistant messages remain unstable until explicitly completed. Fixed session restoration to ignore transient fallback model switches (such as automatic context-promotion or retry fallback) so resumed or resumed-switch sessions revert to the configured default model unless the last change was a user-selected temporary model Fixed in-session /resume to restore both the last user-selected temporary model and persisted plan/goal mode state instead of falling back to the default model with plan mode off. Fixed the /resume session picker overflowing short viewports: the visible window was hardcoded to 5 entries (and assumed 3 lines each), but titled sessions render 4 lines, so on a typical-height terminal the picker's header and search box scrolled off the top and the first entry was hidden until you scrolled the terminal up. The visible-entry count is now derived from the live terminal height (budgeting the worst-case 4-line titled entry plus the picker's chrome), so the whole picker fits the viewport and grows on taller terminals. Fixed the Agent Control Center and Extension Control Center dashboards overflowing the terminal: they were mounted inline below the chat transcript, so the combined height exceeded the viewport — the tab bar and controls scrolled off the top into native scrollback, and every state change yanked the view back to the bottom. Both dashboards now render as full-screen overlays sized to the live terminal height (process.stdout.rows), re-fit on resize, fill the viewport, and reserve space for the footer keyhints so the controls stay visible. Fixed Ctrl+R history search results to remain globally sorted by prompt recency after merging FTS prefix matches with substring fallback matches. Fixed Exa web search with no stored or environment credential to use the public Exa MCP fallback again, preserving the auth storage → EXA_API_KEY → mcp.exa.ai resolution order (#1860). Fixed ACP plan-mode writes to local://PLAN.md so session-local plan artifacts are written to OMP's local artifact root instead of being routed through the editor writeTextFile bridge, avoiding Zen's Internal error and making the plan readable after creation (#1863). Fixed ACP plan mode stranding the agent at plan approval: entering mode: "plan" now registers a standing resolve handler so the agent's resolve { action: "apply" } no longer fails with No pending action to resolve. Nothing to apply or discard. The handler validates the plan file, asks the ACP client to confirm via unstable_createElicitation when the client supports forms, renames the approved plan to local://.md, and exits plan mode so the agent regains write tools for execution (#1869). Fixed provider.appendOnlyContext: "auto" staying inactive for Xiaomi Token Plan/SGLang endpoints, preserving prefix-cache hits without forcing append-only mode globally (#1851). Fixed models.yml compatibility parsing to preserve compat.cacheControlFormat: "anthropic" for custom OpenAI-compatible Claude proxies. (#1845) Fixed the TUI's Settings → Plugins panel reporting "No plugins installed" when only marketplace plugins were installed. The panel now merges PluginManager.list() with MarketplaceManager.listInstalledPlugins() — the same data source the /plugins list slash command and omp plugin list CLI already used — and tags each row with an [npm] / [marketplace] kind badge, a scope tag, and a shadow indicator for project-shadowed user installs. Selecting a marketplace row opens a new MarketplacePluginDetailComponent whose single Enabled toggle calls MarketplaceManager.setPluginEnabled(pluginId, enabled, scope), with read-only metadata (version, install path, installed-at, last-updated, git commit SHA) listed below the toggle. The empty-state now lists both install commands (omp plugin install and omp plugin install @) (#1842). Fixed scoped mnemopi recall in MnemopiSessionState.collectScopedRecallResults/recallResultsScoped to await the async Mnemopi.recallEnhanced so the new auto-derived queryEmbedding flows through. Without this, the embedding-enabled mnemopi backend silently kept running FTS-only on every recall. (#1832) Fixed the SSH tool renderer inlining multiline remote commands into its single-line status header, which produced a malformed cell where the bordered output block opened mid-command. The renderer now drops the command from the header (which keeps only [host]) and renders the full command in a framed section above Output, mirroring the bash renderer. renderStatusLine also flattens any embedded CR/LF in description, meta, and title so no tool can accidentally expand the header into multiple rows (#1828). Fixed tsc --noEmit against packages/coding-agent/tsconfig.json reporting 56 errors under TypeScript 5.x (builtin-registry.ts × 46, agent-session-openai-responses-replay.test.ts × 10). The repo's own gate (tsgo / TypeScript 6.x) already accepted the () => void slash-command handlers, but 5.x rejects them because it does not coerce a void-returning function value into a () => T | undefined slot. The SlashCommandSpec.handle / handleTui signatures and the test's createPersistedSession populate callback are now expressed as a union of two function types (one returning a SlashCommandResult / target, one returning void), so the existing handler bodies typecheck on both compilers (#1821). Fixed omp update leaving @oh-my-pi/pi-natives and the platform-specific @oh-my-pi/pi-natives- leaf at the previous version on bun install -g updates, so the next launch loaded a stale .node file and aborted at validateLoadedBindings with The .node file on disk is from a different release than this loader. omp update now pins the native addon core and the platform leaf to the same version it installs for @oh-my-pi/pi-coding-agent (#1824). @oh-my-pi/pi-mnemopi Breaking Changes Changed Mnemopi.recall(), Mnemopi.recallEnhanced(), Mnemopi.search(), Mnemopi.query(), the module-level recall/recallEnhanced/search/query exports, the BeamMemory.recall/recallEnhanced methods, the free recall/recallEnhanced functions in core/beam/recall, and orchestrateRecall to return Promise so the recall pipeline can auto-derive queryEmbedding from the query text via embedQuery. Callers must await recall calls; pass queryEmbedding: null to opt out of auto-embedding and stay on FTS-only. Changed the MCP entrypoints handleToolCall, callToolJson, and handleJsonRpc in mcp-server/mcp-tools to async so the recall/shared-recall handlers can await the new Promise shape; external MCP transports must await these. Fixed Fixed memory_embeddings never being populated by the production remember/rememberBatch/updateWorking/consolidateToEpisodic paths; embedding generation is now scheduled as a background task on beam.pendingExtractions (mirroring scheduleFactExtraction), so configured providers (fastembed, OpenAI-compatible API, custom) actually run and rows land in memory_embeddings(memory_id, embedding_json, model). (#1832) Fixed recall()/recallEnhanced() never deriving a query embedding from the query text, which silently degraded every deployment to FTS-only regardless of provider configuration. The recall pipeline now auto-calls embedQuery(query) when options.queryEmbedding is undefined; pass null to keep the old FTS-only behaviour. (#1832) Fixed toRecallOptions dropping queryEmbedding between the Mnemopi facade and the beam layer, so callers can now explicitly pin or disable the query vector through the public API. Fixed withMemory (CLI) and withBeam/withSharedBeam (MCP) closing the SQLite handle before background fact-extraction and embedding tasks finished, so short-lived mnemopi store/mnemopi sleep and MCP remember/update paths now drain flushExtractions before close instead of silently dropping memory_embeddings rows. CLI handlers and MCP handleRemember/handleUpdate/handleSleep/etc. are async as a result. (#1832, follow-up to #1833 review) Fixed the process-wide embedQuery() cache in core/embeddings.ts keying by query text alone, which let two Mnemopi instances in the same process with different providers/models cross-contaminate their dense_score rankings. The cache key now includes a WeakMap-assigned provider identity, the resolved model name, and the configured apiUrl, so disjoint runtimes never read each other's cached vectors. (#1832, follow-up to #1833 review) @oh-my-pi/pi-tui Fixed Fixed the OSC 11 appearance poll re-querying every 2s forever on terminals that support Mode 2031 but never change theme, whose repeated OSC 11/DA1 writes cleared the user's active text selection (breaking copy every 2 seconds). The poll now stops as soon as DECRQM confirms Mode 2031 support, since push notifications make polling redundant. @oh-my-pi/pi-utils Fixed Hardened getIndentation against malformed paths: any filesystem error from the .editorconfig probe (e.g. ENAMETOOLONG on oversized garbage path segments) is now swallowed and cached as a miss instead of escaping and crashing the TUI mid-render (#1871). Fixed getIndentation (and the edit renderer's replaceTabs callers) crashing with ENAMETOOLONG/ENOTDIR/etc. when handed a path with an overlong component or a non-directory in its parent chain. Editorconfig discovery now short-circuits to the default tab width on any path component above NAME_MAX (255 bytes) and absorbs any FsError while walking the editorconfig chain — best-effort discovery must never escape as an uncaught exception (#1872). What's Changed fix(robomp): backfill partial-clone blobs before worktree add by @roboomp in #1820 fix(coding-agent): made slash-command handlers compatible with TypeScript 5.x by @roboomp in #1822 fix(coding-agent): sync pi-natives on omp update by @roboomp in #1825 fix(tools/ssh): render multiline remote commands in a framed body block by @roboomp in #1830 fix(mnemopi): populated memory_embeddings on remember and auto-derived queryEmbedding on recall by @roboomp in #1833 fix(ai): preserve kimi-k2.6 reasoning across tool calls by @roboomp in #1839 fix(robomp): serialize same-issue event claims by @roboomp in #1841 fix(tui): list marketplace plugins in settings panel by @roboomp in #1844 fix(ai): honor Anthropic cache-control compat for OpenAI-compatible providers by @roboomp in #1847 fix(providers): add Xiaomi Token Plan support by @roboomp in #1848 fix(providers): cap Kimi K2.x maxTokens on Fireworks/Fire Pass at 32,768 by @roboomp in #1852 fix(providers): enable append-only auto for xiaomi sgLang endpoints by @roboomp in #1854 fix(mcp): update completed tool status icons by @roboomp in #1856 fix(ai): drop image content for DashScope compatible-mode text-only Qwen by @roboomp in #1861 fix(coding-agent): restore Exa MCP fallback by @roboomp in #1862 fix(coding-agent): keep local plan writes off ACP bridge by @roboomp in #1864 fix(utils): swallow editorconfig probe errors to keep TUI rendering safe by @roboomp in #1873 fix(utils): tolerate malformed paths in editorconfig indentation lookup by @roboomp in #1874 Full Changelog: v15.9.0...v15.9.1

v15.9.2

Fri, 05 Jun 2026 13:27:40 +0200

chore: bump version to 15.9.2

v15.9.3

Fri, 05 Jun 2026 17:07:33 +0200

@oh-my-pi/pi-coding-agent Fixed Fixed @-mention auto-read injecting an unrelated, same-named file when a mention did not point at a real path — e.g. an npm scope like @scope/, a partial path, or a bare token. generateFileMentionMessages resolution previously fell back to prefix and repo-wide fuzzy matching (globbing the whole project on every such mention) and auto-read the single "best" guess. Resolution is now exact-only: a mention is auto-read only when it resolves to an existing file or directory; otherwise it is left as prose. The TUI @-selector already inserts the real, complete path before send, so post-send guessing was both unnecessary and the source of the wrong-file reads. Directories still resolve and are listed. Removes the per-mention **/* project scan. @oh-my-pi/pi-tui Fixed Fixed ED3-risk foreground streaming erasing the head of any block that alone overflows the viewport (a tall tool result drawn in one frame, or a multi-line assistant reply growing past the viewport as it streams). The live-region pin committed native scrollback only up to the sealed-prefix boundary (liveRegionStart), so rows of the live block that had physically scrolled above the viewport top were neither pushed into scrollback nor kept in the repainted viewport — they vanished. The commit boundary is now the viewport top: every row above the viewport enters scrollback (only the tail still visible in the viewport stays transient and deferred to the checkpoint). Fixed the same ED3-risk live-region pin duplicating already-committed scrollback rows when a foreground stream's live region collapsed mid-turn (a tool preview shrinking to its compact result, an assistant block re-wrapping shorter, a late tool completion). Because growth commits every row above the viewport top to native scrollback, a subsequent shrink moved the bottom-anchored viewport back across those committed rows and the repaint re-drew them into the viewport — so they appeared twice on scroll-up, and with no prompt-submit checkpoint to reconcile (autonomous multi-turn runs, or the session ending into the welcome screen) the duplicate was baked permanently into terminal history. The pinned repaint now separates commit geometry from repaint geometry: a collapse clamps the repaint to the committed sealed boundary (min(#scrollbackHighWater, liveRegionStart)) instead of re-exposing those rows, leaving native scrollback un-duplicated without emitting ED3 under a possibly-scrolled reader; stale mutable live-region saved lines still reconcile at the next checkpoint. Fixed hiding overlays during ED3-risk foreground streaming on unknown-viewport terminals leaving the overlay's transient rows in native scrollback. Overlay visibility reductions now bypass the streaming deferral path and rebuild once, so hidden dialog/notification sentinels are scrubbed immediately. Fixed ED3-risk / unknown-viewport terminals (including WSL fronted by Windows Terminal) keeping the foreground-stream eager-rebuild mode active after the stream had already settled. A later scrolled content shrink or resize-with-append could then bypass the anti-yank deferral and repaint from stale geometry, jumping the viewport or replaying the wrong rows. The eager opt-in now drops immediately when no teardown render is pending, and the one-frame post-checkpoint suffix-suppression path no longer overrides geometry reflow handling. What's Changed fix(robomp): parameterize bot identity in system prompts by @roboomp in #1933 Full Changelog: v15.9.2...v15.9.3

v15.9.4

Fri, 05 Jun 2026 21:59:43 +0200

chore: bump version to 15.9.4

v15.9.5

Sat, 06 Jun 2026 01:29:01 +0200

@oh-my-pi/pi-agent-core Fixed Surfaced Anthropic stream failures whose message starts with Output blocked by conten as normal assistant error lifecycle events, so interactive clients render content-filter blocks instead of silently dropping the streaming bubble at agent_end. @oh-my-pi/pi-coding-agent Added Added a persistent error banner pinned above the editor when an assistant turn ends on a provider error (e.g. Anthropic's "Output blocked by content filtering policy"). The transcript Error: … line scrolls away as the conversation grows, so terminal turns that ended on a stream error could pass unnoticed; the banner stays in the fixed region above the input and is cleared when the next turn starts. Added bold, underlined, clickable [Image #N] placeholders in the draft editor and sent user-message bubbles, backed by extension-bearing blob-store sidecar files so terminal file:// links open in image viewers. Added the active model identifier (provider/id) to the system prompt's block so the agent knows which model it is running as. Gated by the new includeModelInPrompt setting (default on); the base prompt is rebuilt on a mid-session model switch so the surfaced identifier stays current. Added OLLAMA_HOST support for implicit local Ollama discovery when OLLAMA_BASE_URL is unset, so OMP picks up the same host setting used by Ollama. Added OLLAMA_CONTEXT_LENGTH as a positive-integer context-window override for implicit local Ollama discovery, so users can correct OMP context budgeting without writing per-model overrides. Changed Changed tools.discoveryMode to default to auto, which keeps discovery off for small tool sets and automatically switches to MCP-only tool discovery when more than 40 tools are registered. Fixed Fixed user-message rendering to materialize image links from embedded image blocks when rebuilding chat output, so image placeholders remain clickable after replayed or restored messages Fixed queued/steering user messages carrying a pasted image rendering out of order — sometimes dropping the user bubble below the very tool output it was sent to steer. EventController.#handleMessageStart awaited async image-link materialization between the user message_start and addMessageToChat; since AgentSession.#emit dispatches TUI listeners fire-and-forget, that mid-handler yield let the next synchronously-handled events (assistant message_start, tool execution start/end) append their components first, scrambling transcript order and live-region block boundaries. The bubble is now appended synchronously, with clickable image links still materialized via the synchronous blob-store fallback. Fixed tool execution cards to finalize promptly when a turn is abandoned or completed so stale streaming previews and frozen spinner frames no longer keep transcript rows in the live region Fixed read and search TUI rendering to emit OSC 8 hyperlinks for HTTP URLs, local:// resources backed by files, and filesystem search targets, including line-specific links for search match rows. Fixed aborted streaming assistant messages staying frozen before their red "Operation aborted" label when status rows were appended underneath on ED3-risk terminals. Fixed omp / omp -c stacking a fresh welcome screen and transcript on top of the previous run's leftover terminal scrollback. The cold-launch transcript render was the only session-load path that did not pass clearTerminalHistory, so the TUI's scrollback-preserving initial paint left the prior run's welcome + conversation above the new one; the cold launch now clears native scrollback before painting, matching every in-process session switch. Fixed a long streamed assistant reply dropping its earlier lines on ED3-risk terminals (Ghostty/kitty/iTerm2) once it grew past the viewport — the head scrolled off the top and never reached scrollback, so the reply rendered as a ~viewport-tall circular buffer of only its latest lines. AssistantMessageComponent now reports itself as an append-only transcript block and TranscriptContainer surfaces the resulting commit-safe boundary, so the renderer commits the scrolled-off head to native scrollback instead of discarding it (volatile tool previews stay deferred as before). Security Blocked OSC 8 hyperlink wrapping for URI targets containing terminal control bytes to avoid rendering malformed control-sequence links @oh-my-pi/pi-tui Changed Changed terminal resize handling so any width or height change always performs a clean reset + redraw: the renderer now unconditionally clears the viewport and native scrollback (CSI 2 J / CSI 3 J) and replays the full transcript at the new geometry, replacing the previous matrix of conditional viewport-repaint / history-rebuild / deferred-mutation branches. Multiplexer panes still repaint the visible window in place (pane scrollback cannot be erased), but a resize during active ED3-risk foreground streaming now performs the same clean rebuild rather than downgrading to a non-destructive viewport repaint: the terminal already re-wrapped its saved lines at the old width, so the rebuild must erase them (ED 3) instead of leaving the mis-wrapped history on screen. As a deliberate tradeoff this drops the prior no-overflow and confirmed-scrolled guards on resize: a reader scrolled into history snaps back to the bottom and preexisting shell scrollback above the UI is cleared. Fixed Fixed ED3-risk foreground streaming dropping the scrolled-off head of an append-only live block that alone overflows the viewport (a long streamed assistant reply). The live-region pin again committed native scrollback only up to the live-region start, so once the live block grew past the viewport its earlier rows scrolled above the viewport top but were committed nowhere and repainted nowhere — they vanished, leaving the reply looking like a ~viewport-tall circular buffer. The NativeScrollbackLiveRegion seam now also reports an optional append-only getNativeScrollbackCommitSafeEnd, and the pinned commit boundary is the deeper of the sealed start and that append-only end: rows in [liveRegionStart, commitSafeEnd) above the viewport top commit to scrollback, while volatile live blocks (tool previews that collapse) omit the boundary and keep their mutable rows deferred — preserving the pending-box-above-running-box fix. Full Changelog: v15.9.4...v15.9.5

v15.9.67

Sat, 06 Jun 2026 16:21:43 +0200

@oh-my-pi/pi-ai Fixed Fixed llama.cpp/OpenAI Responses parallel tool calls losing arguments when function_call_arguments.done events omit output_index and item_id, by routing those identifierless final-argument events through the open function calls in item order. (#1970) Fixed local Ollama (openai-responses) turns failing with HTTP 400 invalid reasoning value: "minimal" when a discovered model ran with minimal (or xhigh) thinking. Ollama's OpenAI-compatible reasoning.effort only accepts high|medium|low|max|none, so discovered reasoning-capable Ollama models now carry a compat.reasoningEffortMap remapping minimal → low and xhigh → max; non-reasoning models are left untouched. @oh-my-pi/pi-coding-agent Added Added timeout-pause and timeout-resume eval bridge status events emitted around agent()/llm() operations Added a /copy picker: /copy now opens a fullscreen, outlined tree of recent assistant messages with their code blocks nested beneath (like /tree). Navigate with ↑↓, and Enter copies the highlighted node — a whole message, an individual code block, "All N blocks", or a bash/eval command interleaved with the assistant turn that issued it. A live preview pane shows the selected target, wrapping prose and syntax-highlighting code/commands. Changed Changed eval timeout accounting so delegated bridge calls now suspend the cell watchdog and start a fresh timeout window when runtime control returns Changed IdleTimeout to support reference-counted pauses so overlapping delegated bridge calls keep timeout paused until all calls complete Changed the default app.message.followUp binding from Ctrl+Enter alone to [Ctrl+Q, Ctrl+Enter] so the follow-up shortcut works in Windows Terminal, which does not deliver a distinct Ctrl+Enter event to console apps. Ctrl+Q mirrors the GitHub Copilot CLI default for the same action; existing remaps in ~/.omp/agent/keybindings.yml are untouched, and if another user-remapped action already claims Ctrl+Q, that user binding wins while follow-up keeps Ctrl+Enter. Ctrl+Q is also reserved by ExtensionRunner so an extension cannot register that chord and be silently overwritten by the built-in follow-up handler (#1903). Changed all scrollable TUI pickers and viewports to render through the shared ScrollView right-edge scrollbar for a uniform look, replacing their ad-hoc (N/M) / [a-b/total] text indicators (search hints and the tree filter-mode label are preserved). Covers the session/resume picker, model selector, OAuth provider selector, history search, session tree selector, agent dashboard list, extension list, user-message selector, the raw SSE debug viewer, the autoresearch dashboard overlay, and the session observer overlay. Changed the /model and /switch selectors to dim and skip models whose context windows are smaller than the current chat context. Changed /copy command targets to appear inline with recent assistant messages instead of as a separate "Last bash command" row at the end of the picker. Fixed Fixed the idle Working... loader freezing on ED3-risk terminals with unobservable native scrollback by keeping foreground live-region rendering enabled from agent_start until agent_end, before the first assistant or tool event arrives. Fixed framed tool output blocks rendering one column inset inside tool boxes; modern bordered blocks now span the same width as legacy background-filled tool boxes. Fixed potential TimeoutError aborts for short timeout eval cells during long bridged agent()/llm() work where no progress events are emitted until completion Fixed retry recovery to allow automatic retries without switching models when retry.modelFallback is disabled. Fixed ttsr.enabled: false being ignored at runtime. TTSR rules were still being registered with TtsrManager.addRule and matched against stream deltas even when the global toggle was off, so disabling TTSR did not suppress rule injection or stream abort. The manager now gates addRule, hasRules, and #matchBuffer on the enabled flag, so disabling fully short-circuits the TTSR path. Condition rules fall through to the rulebook bucket instead of being silently swallowed. (#1767) Fixed the Python eval kernel hanging on Windows during import pandas / import numpy, with SIGINT unable to recover the cell. PythonKernel.start() spawned the runner with windowsHide: true, which in Bun maps to the Win32 CREATE_NO_WINDOW flag and detaches the long-lived child from any inherited console — so native extensions like numpy/_core/_multiarray_umath.pyd (and its bundled OpenBLAS/SLEEF thread-pool init) could deadlock inside LoadLibraryExW, and GenerateConsoleCtrlEvent-based SIGINT delivery silently became a no-op. The kernel now hides its window only when the host itself has no console to share (service / piped launch); an interactive TUI launch lets the kernel inherit the parent's console, matching the behavior of python.exe invoked from cmd.exe (#1960). Fixed task renderer crashing the TUI with TypeError: completeData?.map is not a function when a subagent's extractedToolData.yield slot held a non-array value. renderAgentResult (and the live-progress sibling) cast the slot to Array and called ?.map, but optional chaining short-circuits only on null/undefined, so a plain object made .map undefined and threw — taking down every review task render. Both sites now go through normalizeYieldData, which wraps a single object as a 1-element array and drops primitives (#1987) Fixed sdk-async-job-manager-singleton tests flaking under the full parallel suite. The four createAgentSession-based cases ran on the default 5000ms per-test timeout, which two real session startups can exceed when test:ts saturates the machine across packages; on timeout the still-running test body and afterEach reset raced, surfacing a spurious "Unhandled error between tests" on the AsyncJobManager.instance() assertion. They now carry an explicit 60000ms timeout, matching the convention used by the other session-creating tests in this suite. Fixed streaming eval, bash, ssh, and task call previews overflowing the live transcript viewport and cutting off their top while pending. A volatile tool block taller than the viewport could strand its scrolled-off head out of native scrollback on ED3-risk terminals (committed nowhere, repainted nowhere) until the result landed. The pending eval source preview now follows the streaming edge in a bounded 12-line tail window (newest lines pinned to the bottom, "… N earlier lines" on top) so you can watch the code being written without the box overflowing; bash/ssh commands and task context use a bounded head+tail window. Ctrl+O still lifts the cap for a full view. Fixed the streaming write call preview ignoring Ctrl+O so the expand toggle was a no-op while a file was being written. Unlike the eval/bash/ssh/task streaming previews, formatStreamingContent never received the expanded flag, leaving the preview pinned to a bounded 12-line tail window even after pressing Ctrl+O — so on a large write you could not widen past the streaming edge until the tool result landed. The preview now lifts the cap to the full file (head through tail) when expanded, matching the documented streaming-preview behavior of the other tools. Fixed turn-ending provider errors rendering twice — once as the transcript's inline Error: … line and again in the pinned banner above the editor (added in 15.9.5). The inline line is now suppressed while the same error is mirrored in the banner and restored to the transcript when the banner clears at the next turn, so the error stays in history without the duplicate render at the error moment. Removed Removed the /copy last|code|all|cmd subcommands; every copy target is now reachable by picking it in the /copy tree. @oh-my-pi/hashline Breaking Changes Changed hashline file section headers from ¶PATH#TAG to [PATH#TAG] so model-authored edits use ASCII delimiters instead of a pilcrow sigil. Fixed Fixed missing-header diagnostics and copied-content prefix stripping to consistently teach and recognize 4-hex snapshot tags. @oh-my-pi/pi-tui Added Added setPaddingX to Box so horizontal padding can be updated programmatically after creation Added ScrollView, a fixed-height viewport component for pre-rendered lines with optional right-edge scrollbars and imperative scroll/page controls. Added optional Terminal.hasEagerEraseScrollbackRisk() so custom/test terminal implementations can override the global ED3-risk profile without mutating the shared TERMINAL object. Changed Changed SelectList to render its visible window through ScrollView, replacing the (N/M) text scroll indicator with a uniform right-edge scrollbar (the type-to-search hint line is preserved). Fixed Fixed unknown-viewport deferred renders freezing bottom-anchored live chrome; deferred history mutations can now repaint only the active-grid bottom row with relative cursor movement, so spinner/status tails keep advancing without rewriting rows a scrolled reader can still see. Fixed autocomplete popups freezing live repaint on ED3-risk macOS/POSIX terminals with unknown native viewport position; direct autocomplete shrink frames now repaint the live viewport without zero-byte deferral and preserve the old bottom anchor when padding can clear stale popup rows without duplicating committed scrollback. Fixed focused Up/Down navigation on ED3-risk macOS/POSIX terminals replaying the whole transcript after dirty foreground-stream renders; selector/editor frames now repaint non-destructively instead of emitting CSI 3 J on every arrow-key move (#1962). Fixed tmux (and screen/zellij) pane scrollback losing the head of a long streamed assistant reply once it grew past the visible pane, and stranding the chrome/footer in pane history after a later collapse — producing the "repeating chunks and missing sections" reporters saw when scrolling back through tmux pane history (#1974). The renderer's foreground-streaming cap-to-viewport branch (introduced in 15.9.2 for ED3-risk hosts that can checkpoint-rebuild later) also activated inside multiplexers, where checkpoint reconcile is a no-op (refreshNativeScrollbackIfDirty short-circuits because \x1b[3J cannot erase pane history). Every streaming frame clipped lines to the visible tail and reset #scrollbackHighWater to 0, so any row that scrolled above the viewport top was committed nowhere — pane history stayed empty until streaming ended. Meanwhile #planLiveRegionPinnedRender was explicitly disabled for multiplexers, but its #emitLiveRegionPinnedRepaint is built from the exact primitives tmux accepts (relative cursor moves, per-line \x1b[2K, \r\n to scroll the sealed prefix past the viewport bottom) and never emits \x1b[2J/\x1b[3J. The pinned planner now runs in multiplexers too, the cap branch skips them, and the diff/append path commits incrementally into pane history; the actively-mutating live tail stays in the visible viewport only. What's Changed fix(hashline): accept spaces in edit paths by @roboomp in #1766 fix(keybindings): default Ctrl+Q for follow-up so Windows Terminal works by @roboomp in #1905 fix(eval): stop detaching the Python kernel's console on Windows by @roboomp in #1961 fix(tui): avoid dirty scrollback replay on arrow input by @roboomp in #1963 fix(ai): preserve llama.cpp parallel tool arguments by @roboomp in #1971 fix(tui): honor resume clear replay before initial paint by @roboomp in #1973 fix(tui): commit tmux pane history during streaming via pinned emit by @roboomp in #1975 fix(lsp): support rust-analyzer workspace loading by @roboomp in #1977 test(tui): widened slash autocomplete settle slack past debounce jitter by @roboomp in #1981 fix(coding-agent): guard task renderer against non-array yield slot by @roboomp in #1989 fix(coding-agent): honor ttsr.enabled: false in TtsrManager by @QianYan-Art in #1988 fix(coding-agent): allow retry without model fallback by @metaphorics in #1929 Add ScrollView component by @enieuwy in #1969 New Contributors @QianYan-Art made their first contribution in #1988 Full Changelog: v15.9.5...v15.9.67

v15.9.69

Sat, 06 Jun 2026 20:13:59 +0200

chore: bump version to 15.9.69

v15.10.0

Sun, 07 Jun 2026 00:29:35 +0200

@oh-my-pi/pi-ai Added Added a dependency-free @oh-my-pi/pi-ai/effort module exporting the Effort enum and THINKING_EFFORTS, split out of model-thinking so hot-path consumers can import the thinking levels without pulling in model-thinking and its provider-compat dependency graph. The package barrel still re-exports both names, so existing imports are unaffected. Fixed Fixed Antigravity usage provider emitting one bar per model instead of deduplicating by tier — a single account's 15+ model entries now collapse to one bar per tier, matching the shared-quota reality of the upstream API. Fixed Antigravity usage reports missing email and accountId in metadata, so the /usage display and the deduplicator can associate reports with their credentials. Fixed usage-report dedup ignoring projectId for Google Cloud providers, preventing duplicate credential entries from being recognized as the same account. Fixed Cloud Code Assist (Antigravity / Gemini CLI) rejecting the github tool with HTTP 400 when the pr parameter schema contained anyOf: [string, array]. The CCA mixed-type combiner collapse picked the first non-null type (string) but indiscriminately copied type-specific keys from variant branches — items from the array variant leaked onto the string-typed result, producing {type: "string", items: {...}} which Google's API rejects as invalid. The collapse now filters merged variant fields against the winning type's allowed key set. (#2002) Fixed OpenAI Responses-family providers (Codex, OpenAI Responses, Azure Responses) rejecting requests with 400 No tool output found for function call … after the user branched/navigated the session tree to a node that ends on a tool call (the tool-result child is dropped from the reconstructed history) or after a turn was aborted/crashed between the call streaming and its result persisting. The converters now synthesize a placeholder function_call_output/custom_tool_call_output immediately after any unpaired function_call/custom_tool_call, symmetric to the existing orphan-output repair, so the model still sees the call and can recover instead of the whole request 400ing. Fixed Anthropic-compatible reasoning endpoints losing prior-turn reasoning on continuation requests when they emit unsigned thinking blocks. convertAnthropicMessages treated unknown endpoints as signature-enforcing and demoted unsigned reasoning to type: "text", which destabilized tool-call argument serialization on the next turn — the upstream symptom behind the args?.ops?.map is not a function crash reported against the todo tool. Official api.anthropic.com keeps the conservative text fallback; non-official anthropic-messages reasoning models now replay unsigned reasoning as native type: "thinking" (#2005). @oh-my-pi/pi-coding-agent Breaking Changes Replaced the providers.parallelFetch boolean setting with the providers.fetch enum (auto / native / trafilatura / lynx / parallel / jina) that selects the URL reader-backend priority for the read/fetch tool, mirroring providers.image/providers.webSearch. Existing configs are migrated automatically: the legacy key is dropped and the new auto default applies. Added Added a GitHub Actions read handler to the read/web-fetch GitHub scraper. Fetching github.com/{owner}/{repo}/actions/runs/{id} renders the run metadata plus a per-job breakdown (steps listed for any job that did not succeed), and …/actions/runs/{id}/job/{id} (also the API-style …/jobs/{id}) renders a single job's metadata, step table, and full plain-text logs. Logs are fetched via the actions/jobs/{id}/logs redirect using GITHUB_TOKEN/GH_TOKEN when present, with the per-line ISO timestamp prefix and leading BOM stripped; the section degrades to an explicit notice when logs are unavailable (no token, private repo, or expired/unfinalized run). Changed Changed eval agent() subagents so they are never subject to the task.maxRuntimeMs wall-clock cap. The parent cell's idle watchdog is already suspended for the entire bridge call (withBridgeTimeoutPause), so a long-running fan-out/recovery workflow must not be killed by a per-subagent runtime limit. runEvalAgent now passes maxRuntimeMs: 0 to runSubprocess, which honors an explicit ExecutorOptions.maxRuntimeMs override over the inherited setting. Changed interactive timing behavior so PI_TIMING=x pi preloads the module timer before the CLI graph loads and includes the (modules) report. PI_TIMING=full now also exits after printing, matching PI_TIMING=x, so full module reports are usable for cold-start measurement without launching the TUI. Added the root dev:timing script for the same profiled startup path. Changed coding-agent startup imports so normal TUI launch imports InteractiveMode directly, keeps print/RPC/ACP runners on their branch-only paths, and moves marketplace auto-update work behind a lightweight deferred starter. Changed cold-launch setup gating so the full setup wizard (every scene plus the overlay and their TUI/OAuth/web-search/theme dependencies) is no longer statically imported by main.ts. The current setup version now lives in a tiny dependency-free modes/setup-version module, and the wizard barrel is lazy-loaded only when the stored setup version is stale or the wizard is forced — the common up-to-date launch skips loading it entirely. Changed cold-launch startup imports so the hot-path CLI files no longer pull the full @oh-my-pi/pi-ai barrel: commands/launch.ts and cli/args.ts import THINKING_EFFORTS/Effort from the tiny @oh-my-pi/pi-ai/effort module, and config/model-registry.ts now imports its ~20 symbols from narrow subpaths (api-registry, model-cache, model-manager, model-thinking, models, provider-models, types, utils/event-stream) instead of the barrel — so launching no longer eagerly loads every provider, auth, OAuth, and usage module re-exported by the barrel. Changed the read/fetch HTML reader-backend priority to native > trafilatura > lynx > parallel > jina (was parallel > jina > trafilatura > lynx > native). The in-process native htmlToMarkdown runs first — instant, no network, full-fidelity — so the common case no longer depends on a remote service, and a stalled remote backend can no longer mask it. Selecting a specific backend via providers.fetch tries it first, then the rest fall back. The low-quality gate (>100 chars and not isLowQualityOutput) now applies uniformly to every backend; when none clears it, the highest-priority substantial-but-low-quality output is still surfaced so the llms.txt / document-extraction fallbacks keep running. Fixed Fixed eval agent() failures surfacing as an opaque RuntimeError: bridge call '__agent__' failed with no reason. When a subagent aborted, runEvalAgent built its failure message with result.error ?? result.stderr ?? result.abortReason ?? …, but result.stderr is the empty string on a clean abort (and result.error is gated on a non-empty stderr), so the nullish chain stopped at "" and never reached abortReason. The empty string propagated through the loopback bridge and the Python prelude's RuntimeError(msg or "bridge call … failed"), discarding the real reason. The chain now uses || so an empty stderr falls through to abortReason. Fixed subagent aborts being mislabeled as the generic "Cancelled by caller" when the abort originated inside the subagent's own turn (stopReason: "aborted" with no caller signal and no runtime-limit timer). runSubprocess now prefers the aborted assistant message's errorMessage (e.g. "Request was aborted" or a specific stream error) for that case, while a real caller signal or wall-clock abort still reports its precise reason. Fixed a long streaming tool preview that alone overflows the viewport dropping its scrolled-off head on ED3-risk terminals (ghostty/kitty/iTerm2/…). When expanded with Ctrl+O, a streaming write (content streaming in) and a streaming eval (stdout streaming below its fixed code cell) render top-anchored and grow append-only, but the tool block never reported itself append-only to the transcript, so the renderer's commit-as-you-go boundary stopped at the block start and the earlier rows that scrolled above the viewport were committed nowhere — they vanished, leaving the preview looking like a viewport-tall circular buffer. ToolExecutionComponent now implements isTranscriptBlockAppendOnly() (gated on isTranscriptBlockFinalized(), so it also covers partial-result streams like eval), delegating to a renderer-declared isStreamingPreviewAppendOnly predicate so the expanded stream commits its head exactly like a streamed assistant reply. Collapsed previews (bounded sliding tail windows) and finalized/result previews (which can collapse to a capped view) stay deferred. Fixed read/fetch silently dropping whole list sections on pages with malformed list markup — stray , text, or nodes as direct children of (e.g. the Alacritty changelog). The Jina reader (previously tried before the local renderers) mis-extracts such lists, returning empty Added/Changed sections; the native in-process renderer now runs first and preserves the full content. Fixed /usage aggregate amount fallback using raw limits.length as account count — now counts unique accountId values from limit scopes, so N limits from a single account no longer display as "N accts". Fixed /usage account labeling falling back to "account N" for providers that use projectId as their primary identity (e.g. Google Antigravity, Gemini CLI) — projectId from report metadata is now considered before the generic fallback. Fixed the todo tool's TUI renderer crashing with TypeError: args?.ops?.map is not a function when a streaming tool-call delta surfaced a non-array ops field (mid-stream parseStreamingJson shapes like { ops: "[{" }, or [null] entries before fields arrive). The renderer now treats non-array ops, non-object entries, and non-array items as missing structure instead of crashing, which also stops the spam-warn cascade that followed each malformed delta. Paired with the Anthropic-side reasoning-replay fix in packages/ai (#2005). Fixed Python eval agent() collapsing subagent runtime-limit aborts (and other empty-stderr aborts) into a generic RuntimeError: bridge call '__agent__' failed. runEvalAgent coalesced the failure message with ??, which stopped at the empty stderr and never reached abortReason, shipping an empty error through the loopback bridge. The bridge now prefers abortReason for aborts and trims empty stderr/error out of the fallback chain, so Python surfaces the actionable reason (e.g. Subagent runtime limit exceeded (task.maxRuntimeMs=900000)) (#2006). @oh-my-pi/pi-tui Changed Reworked the DEC 2026 synchronized-output default policy: a positive DECRQM mode-2026 report now enables sync (previously a report could only disable it), so conservatively defaulted-off hosts that actually support it — current Zellij, tmux master, foot, contour, mintty — are upgraded at runtime. The static allowlist also covers Alacritty and the VS Code terminal, honors a TERM_FEATURES Sy advertisement and WT_SESSION (Windows Terminal / WSL), and no longer blanket-disables SSH (DEC 2026 passes through to the outer terminal). Risky multiplexers still start off and rely on the probe. Added synchronizedOutputUserOverride() as the shared opt-out/force resolver. Fixed Fixed WSL/Windows Terminal row flicker while typing by repainting changed text rows before clearing only their stale suffix (#2011). Fixed terminals that support DEC 2026 still tearing/flickering because the renderer ignored a positive DECRQM capability report and kept synchronized output off — most visibly WSL + Windows Terminal, Alacritty (≥0.13), and the VS Code terminal (≥1.108), which were detected yet refused sync. @oh-my-pi/pi-utils Changed logger.printTimings() (the PI_TIMING startup tree) now surfaces two previously-invisible regions: a (before instrumentation) line for runtime init / uncaptured pre-marker work, and an (unattributed self) line for the root span's own untimed work so the gap between visible top-level spans and Total is no longer swallowed. Total is now labelled (since first marker) to make the window explicit. The restored module-timer.ts preload can feed module spans into the report: each module records onLoad → final top-level marker as total, a prepended body marker → final marker as body/TLA, and resolved static imports as a bounded dependency tree so the report separates graph wait from actual top-level module work. What's Changed fix(ai): strip type-specific keys when CCA mixed-type collapse picks non-matching type by @basedcorp99 in #2002 fix(usage): sanitize Antigravity /usage display — dedupe by tier, fix account count, merge window data by @basedcorp99 in #2004 fix(coding-agent): harden todo renderer against malformed streaming args by @roboomp in #2007 fix(eval): surface subagent abort reason through Python agent() bridge by @roboomp in #2008 docs(web-search): updated kagi description to v1 endpoint by @roboomp in #2010 fix(tui): reduce WSL row flicker while typing by @roboomp in #2012 fix(debug): wait for dlv unix socket before connecting by @roboomp in #2014 Full Changelog: v15.9.69...v15.10.0

v15.10.1

Sun, 07 Jun 2026 18:25:53 +0200

@oh-my-pi/pi-agent-core Added Added optional promptCacheKey support to AgentOptions and Agent via a new promptCacheKey property so providers can receive a caller-provided prompt cache key Added optional ApiKeyResolveContext parameter to getApiKey in AgentOptions and AgentLoopConfig so key resolvers can receive retry context Changed Enabled streaming API calls to re-resolve credentials through the getApiKey callback when retries occur after authentication-related errors Agent.abort(reason?) now forwards reason to the underlying AbortController, and the synthesized aborted assistant message carries that reason on errorMessage (string or non-AbortError Error message) instead of always defaulting to "Request was aborted". Bare abort() is unchanged. Fixed Fixed handling of short-lived API keys so that expired tokens are retried with a refreshed value during 401/usage-limit failures Ensured fallback API key resolution uses the initially configured static apiKey when getApiKey is present Wrapped oneshot LLM completions (instrumentedCompleteSimple: handoff, compaction/branch summaries) in an EventLoopKeepalive. These run outside the agent #runLoop, so without the keepalive Bun's event loop stopped servicing timers while parked on the completion promise — freezing host spinners (e.g. the /handoff loader) until an unrelated terminal resize poked the loop into rendering again. @oh-my-pi/pi-ai Breaking Changes Removed the onAuthError option from stream request options and shifted auth retry handling to resolver-based apiKey behavior, requiring callers using custom auth-retry hooks to migrate Added Added ApiKeyResolver and ApiKey auth helpers, including isApiKeyResolver, isAuthRetryableError, resolveApiKeyOnce, and withAuth, and exported them from the package root Added support for a function-valued apiKey in SimpleStreamOptions so a single stream request can refresh or rotate credentials during retry Added forceRefresh credential option to AuthStorage.getApiKey and rotateSessionCredential support for session-level credential rotation after auth failures Added AuthStorage.resolver(provider, options) method that builds an ApiKeyResolver implementing the a/b/c auth-retry policy directly on the storage instance Changed Changed gateway and stream auth flows to share the a/b/c retry policy, refreshing the same session credential first and then switching to a sibling credential on repeated auth failures Fixed Fixed streaming auth retries to handle 401 and usage-limit errors before replay-unsafe content is emitted, including failures surfaced only via errorStatus Fixed tool argument validation to coerce singleton non-string values into arrays when the schema expects an array, preventing Anthropic-compatible models that emit todo.ops as an object from getting stuck in repeated validation-error loops. (#2026) Fixed streaming retries to buffer and suppress partial start events from failed auth attempts so only clean retried events are delivered Fixed the HTTP 400 raw-request dumper (appendRawHttpRequestDumpFor400) littering the real ~/.omp/logs/http-400-requests directory during tests. Provider suites exercise the 400 error path with mocked fetch responses, which the dumper could not distinguish from genuine failures; it now skips persistence under the Bun test runner (isBunTestRuntime()). Fixed Anthropic Opus requests unnecessarily forcing tool_choice.disable_parallel_tool_use, allowing Claude Opus to use the provider's default parallel tool-calling behavior again. Fixed parallel function_call items losing arguments against llama.cpp's OpenAI Responses endpoint (/v1/responses), where every call but the last finalized with {} and the agent rejected them with path: Invalid input: expected string, received undefined. llama.cpp's to_json_oaicompat_resp emits output_item.added with only item.call_id (no item.id, no output_index) while the matching function_call_arguments.delta carries item_id: "fc_". processResponsesStream now registers function-call and custom-tool-call items under item.call_id as a secondary lookup key (alongside item.id/output_index) so identifier-deviant hosts route deltas and done events to the right block. (#2015) Fixed PI_REQ_DEBUG response recording truncating the captured body when a streamed response was cancelled mid-flight. The response tee in wrapResponse could call FileRequestDebugResponseLog.close() from both the cancel callback and the resumed pull (which observes done once the source reader is cancelled); the second caller saw the handle already nulled and returned before the first caller's pending write flushed, so the .res.log lost the already-buffered chunk. close() now memoizes its flush-and-close promise so every caller awaits the same completion. @oh-my-pi/pi-coding-agent Added Added display.smoothStreaming setting (default true) to let users enable or disable smooth assistant-stream text reveal Added /tan slash command to fork the current conversation into a background agent so tangential work can continue asynchronously while your main session stays active Added a background /tan dispatch message that records the handoff in the transcript and marks the delegated work as non-blocking Added providerPromptCacheKey support to CreateAgentSessionOptions so /tan background sessions can reuse the parent session’s prompt-cache lineage Added session cloning for /tan runs with copied artifacts and shared MCP proxy tools Added SessionManager.forkFrom’s optional suppressBreadcrumb mode to avoid breadcrumb updates when forking background /tan sessions Added OSC 5522 enhanced paste handling in InputController, so terminal clipboard events are decoded as image or text payloads and inserted without passing raw paste sequences to the editor Added bracketed image-path paste support in CustomEditor so a single pasted image file path (PNG/JPEG/GIF/WEBP) is loaded from disk and inserted as an image candidate Added direct support for Image #N insertion from pasted local image paths by routing successful image-path pastes through the same image normalization and resize flow as clipboard image pastes Added /fresh to rotate the provider-facing session id and clear in-memory provider stream/cache state without changing the local session file. Added a ChatBlock transcript primitive (modes/components/chat-block.ts) and a single ctx.present(...) sink (with ctx.resetTranscript()) so chat output is mounted in one place instead of the repeated chatContainer.addChild(...) + ui.requestRender() pattern scattered across controllers. ChatBlock carries a React/Svelte-style lifecycle — onMount starts effects, onCleanup registers teardown, finish() self-completes (stops timers and freezes the block at its final content), and dispose()/resetTranscript() tears everything down — so animated blocks own their own resources instead of leaking setInterval/requestRender bookkeeping into callers. The MCP "Connecting…" spinner is now such a block. Added a framedBlock output-block helper (tui/output-block.ts) plus a borderColor override and applyBg: false (no background fill) on output blocks, a renderStatusLine iconOverride, and an icon.search (magnifier) theme symbol — so tool renderers can draw self-contained muted-outline frames and search-family tools can show a magnifier instead of a checkmark. Changed Changed the bash tool frame to use a plain top rule instead of repeating "Bash" in the title bar, and folded minimizer raw-output artifact links into the status footer as Artifact: . Changed grouped read output to use a white filled-circle mark for the group/single-read success state and omit duplicate per-file success marks inside multi-read groups. Changed assistant streaming output to reveal text incrementally at 30 FPS with grapheme-safe adaptive catch-up, instead of replacing the whole message chunk-by-chunk Changed shimmer-driven TUI animations (working text, pending bash/eval borders, and theme activity-spinner documentation) to render at 30fps instead of 60fps. Changed running task tool agent rows to use a static • marker and shimmer only the subagent name, leaving descriptions, stats, and nested tool detail text solid while removing the rotating status glyph from those rows. Changed settings singleton method access to reuse bound methods for the active instance instead of allocating a new bound function on every settings.get lookup. Changed plan-mode approval to keep the drafted local://-plan.md file at its original name as the canonical plan path, so approved plans are no longer renamed when leaving plan mode Changed plan-mode write enforcement so only local:// artifact files are writable during planning, blocking working-tree edits and allowing scratch or draft plan files in the local artifact area Changed the todo tool result renderer to stop redrawing every phase's full task list on each update: when a multi-phase list is rendered collapsed (the default, not manually expanded), only phases the latest update touched — the phase holding the in_progress task, any phase with a just-completed task, and phases named by the ops that ran (init counts as touching all) — render their tasks; untouched phases collapse to a one-line N. Name done/total summary. When call args are unavailable (e.g. transcript rebuilds) it falls back to the in_progress/completed-transition signals, and the manual expand toggle still shows every task. Also dropped the blank separator line previously inserted between phases. Changed non-agent API operations (title and commit-message generation, image generation, web search, eval llm(), auto-thinking classifier, memory consolidation) to use session-aware API key resolution with auth retries via registry.resolver() / authStorage.resolver(), refreshing the active credential before rotating to another account Changed image generation to wrap every provider fetch branch in withAuth, so 401 / usage-limit errors trigger credential force-refresh and rotation for authStorage-backed providers (OpenAI-hosted, antigravity, xai-oauth) while env-only providers (openrouter, gemini) stay single-attempt Changed web-search providers using authStorage.getApiKey (anthropic, exa, tavily, parallel, synthetic, zai, kimi) to wrap HTTP calls in withAuth for automatic credential rotation on 401 / usage-limit errors Changed the directory grouping for find, search, ast_grep, ast_edit, and lsp diagnostics from a single flat # dir/ heading per immediate directory to a multi-level tree that folds the common path prefix into one heading. Previously every group repeated the full directory path — so results rooted outside cwd printed the absolute prefix (e.g. /Users/me/proj/) on every heading and nested directories were never collapsed. Now a single-child directory chain folds into one heading (# packages/pkg/src/, including an absolute root for out-of-cwd results), subdirectories nest one # deeper (## nested/ → ### child.ts), and each directory's own files are listed before its subdirectories. TUI hyperlink reconstruction tracks the nested directory stack across the whole output so file and code-frame links keep resolving to the correct absolute paths. Changed the plan-mode approval surface from an inline transcript block plus a separate bottom selector into a single fullscreen overlay (like /copy) and overhauled its navigation. The overlay now renders the plan per-section through ScrollView (line-level ↑/↓ scroll, Shift+↑/↓ to scroll faster, PgUp/PgDn, g/G) with no stray per-line …, and — when the terminal is wide enough and the plan has ≥2 headings — shows a compact VS Code-style section sidebar (the redundant plan-title heading and any "Contents" label are omitted). Focus moves between regions with Tab/Shift+Tab (and flows at the edges: Down past the last section or the bottom of the body drops into the approval options; Up steps back), while the sidebar glows to track the scrolled section. The sidebar can fast-jump between sections, delete a section (with u undo), and annotate sections with feedback (a); deletions and annotations are collected into refinement feedback that is submitted back to the model when the operator picks "Refine plan". Mouse works too: clicking an approval option activates it, clicking a sidebar section jumps to it, and the wheel scrolls the plan. ←/→ always drive the model-tier slider, Enter confirms, the external-editor key opens the plan, and Esc cancels. The overlay borrows the terminal's alternate screen buffer for its lifetime (fullscreen overlay), so the transcript stays put on the normal screen instead of bleeding through scrollback behind the modal. Changed the interactive controllers (command, MCP, selector, extension-UI, event), debug panels, and the status/error/warning helpers to render chat output through ctx.present(...) instead of appending to chatContainer and calling ui.requestRender() directly; transcript rebuilds dispose live blocks via ctx.resetTranscript() so animated blocks' timers stop on reset. Changed tool-execution block rendering so the container (ToolExecutionComponent) is a transparent passthrough — it no longer inserts a top/bottom blank line, adds left/right padding, or paints a state-colored background behind tool output. Tools with substantial body now self-frame with a muted outline and the tool title in the frame's top bar (edit/apply_patch, write, ask, todo, github, goal, inspect_image, search_tool_bm25, task), matching the already-framed bash/read/eval/debug/web_search/lsp blocks, while streaming/in-progress and trivial results collapse to a clean status line. The search-family list tools (find, search, ast_grep) and job render frameless/minimal; find/search/ast_grep show a magnifier on success instead of a checkmark, and job drops its Job: label prefix (the per-job rows are self-describing). The search_tool_bm25, github, and inspect_image frames draw with no background fill, and inspect_image's label was shortened to Inspect. Changed the plan-mode active prompt (prompts/system/plan-mode-active.md) to make plans decision-complete and cut filler. Added an Objective framing ("another engineer can execute end-to-end without making a single design decision"), a shared "Resolving Unknowns" section (explore discoverable facts before asking; reserve ask for non-derivable preferences/tradeoffs with 2–4 options + a recommended default), and a single shared "The Plan" structure (Context / Approach grouped by behavior not file-by-file / ≤5 Critical files / Verification / Assumptions) that replaces the per-branch structure guidance previously duplicated across the iterative and parallel workflows. Added explicit prohibitions on sections that decide nothing (Non-Goals, Out of Scope, Alternatives Considered, Risks/Mitigations boilerplate, Future Work), on enumerating every file/line, and on inventing schema/validation/precedence policy the request never established. Changed completion notifications (completion.notify) to fire whenever the agent yields its turn, including in the foreground. The agent_end notification was previously gated behind background mode (isBackgrounded), so an ordinary foreground turn never emitted one; the gate is gone and the desktop toast now fires on every normal turn completion (still skipped for aborted/error turns and when completion.notify is off). Changed the in-progress task tool block to keep the shared context brief (# Goal / # Constraints background) visible after the first progress snapshot arrives, instead of dropping it the moment the streaming call view was replaced by the result frame, and to stop animating a spinner/clock next to the Task frame header while running — the per-agent body lines already carry their own running spinner, so the header now shows a static state icon (matching the completed/failed header icons). The context is rendered through a shared buildContextSection helper that also undoes per-field double-encoding, so the brief reads cleanly in the result frame even though renderResult receives the raw (un-repaired) tool args. Changed the messaging shown when you press Esc to interrupt a streaming turn from the ambiguous Operation aborted / Tool execution was aborted: Request was aborted to Interrupted by user, so a deliberate user interrupt no longer reads like an internal failure. Every Esc/flush interrupt path (onEscape while streaming, the queued-message restore-and-abort path, and the empty-submit queue flush) threads the reason through AgentSession.abort({ reason }) → Agent.abort(reason) so it rides the AbortController onto the aborted assistant message's errorMessage; the turn label renders it verbatim on both the live and replay paths, and the synthetic placeholder results paired with in-flight tool calls now read Tool execution was aborted: Interrupted by user. Aborts that carry no reason still fall back to the retry-aware Operation aborted generic. Transcript label resolution is centralized in resolveAbortLabel (session/messages.ts). Removed Removed the /background (and /bg) slash command and the background-mode subsystem it was the sole entry point for — InteractiveMode.isBackgrounded, createBackgroundUiContext, handleBackgroundEvent, and every isBackgrounded guard across the input/event/extension-UI controllers and UI helpers. The command suspended the whole process group via SIGTSTP (a leftover testing shortcut) instead of detaching the running agent, which is not the expected workflow — use terminal panes or a multiplexer instead. Fixed Fixed inline find and search result blocks to align with grouped read output and render their success headers with the normal tool-title color instead of accent blue. Fixed the working-status shimmer to opt into the loader's 30fps animated-message repaint path while keeping both the status spinner and pending bash/eval tool spinners on their normal 80 ms glyph cadence. Fixed consecutive read tool calls failing to collapse into a single grouped block when a reasoning model emits one read per completion ([thinking, read]). The read group was reset on every assistant message_start, so each read rendered as its own one-entry Read … line; now a read run accretes across completions and is broken only by a rendered non-empty text/thinking block, a non-read tool, or a user/IRC message — matching the transcript-rebuild path. ReadToolGroupComponent now reports its live/finalized state so the growing Read (N) header repaints correctly on native-scrollback (risk) terminals. Fixed the task tool shared-context brief rendering raw Markdown headings (# Goal, # Constraints) inside framed call/result blocks instead of using the normal Markdown renderer. Fixed the animated pending border on bash/eval blocks leaving a frozen dark "bar" segment behind after a backgrounded command finalized through the async update path. Once a command is auto-backgrounded (details.async.state === "running") the block stays "partial" in the TUI until the async job-manager delivers the final result, but it also gets committed to native scrollback — so a mid-sweep shimmer frame baked a stray darkened border segment into the committed copy. The border now stops animating (and the 60fps redraw loop stops) the moment a block enters the backgrounded state, so the committed frame is a clean static border. Fixed cold omp launch to clear native terminal history on the first paint, avoiding a once-per-launch duplicate welcome/transcript copy before the normal session replay. Fixed plan approval resolution so resolve with action: "apply" can still find the plan file when extra.title is missing or stale by falling back to the current plan path and most-recent local plan artifacts Fixed the search-family tool magnifier glyph (find, search, ast_grep, search_tool_bm25) to use the accent title color instead of success green, so the icon matches the tool title in the status header instead of standing out Fixed TTSR stream interrupts to pass the matched rule name through the abort reason, so aborted in-flight tool placeholders say why they were stopped instead of Request was aborted. Fixed URL reads for binary/special payloads to reuse local readers: remote archives list their root entries, SQLite databases show their table overview, notebooks render as editable cells, and unrenderable binary returns a metadata notice instead of decoded byte garbage. Fixed pasted image-file paths that cannot be loaded to fall back to normal text paste with status feedback instead of disappearing. Fixed tool-output file paths not being clickable OSC 8 file:// hyperlinks in several renderers. read titles for plain text and image files (the common case) emitted no link at all because the renderer only linked when a resolvedPath was recorded — which the ordinary file/image read paths never set, keeping the absolute path only in meta.source; the renderer now falls back to that source path. write headers were never wrapped in a hyperlink and now link to the absolute path written (file, archive entry, SQLite, and conflict resolutions). edit/apply_patch headers wrapped the model-supplied (often cwd-relative) argument path, producing a root-anchored file:///rel/path URI; they now link the absolute details.path instead. Finally, search, ast_grep, and ast_edit produced doubled link targets (/proj/src/src/file.ts) for searches scoped to a subdirectory, because the renderer resolved the cwd-relative display paths against the scope directory rather than cwd — the scoped-search base is now the session cwd (with the scoped file's absolute path still seeding single-file body lines). Fixed omp dry-balance --bench to recover from 401 token failures by re-minting the failing OAuth credential in place before switching accounts Fixed the bash tool corrupting commands that embed multi-byte UTF-8 (e.g. ✓/× inside a grep -E pattern) ahead of a trailing | head/| tail. The bash.stripTrailingHeadTail rewrite cut at char-offset positions reported by brush-parser while slicing the command by byte offset, so the trailing-pipe strip landed mid-pattern and dropped the closing quote — turning … |✓|×|XCTAssert" | tail -80 into … |✓|×-80 and making execution fail with pi-natives:command: unterminated double quote. Fixed in pi_shell::fixup (@oh-my-pi/pi-natives). Fixed omp dry-balance --bench to recover from 401 token failures by re-minting the failing OAuth credential in place before switching accounts Fixed duplicate file entries in grouped outputs for find, search, ast_grep, ast_edit, and lsp diagnostics when the same path appeared multiple times Fixed search, grep, and edit output rendering so repeated directory group blank-line boundaries no longer break nested path/link reconstruction Fixed omp dry-balance --bench flooding the terminal with staircased, duplicated spinner/status lines (and an indented summary) when the tty has ONLCR/OPOST disabled (raw mode). The interactive progress region separated rows with a bare LF and repositioned with a column-preserving \x1b[A cursor-up, both of which only land at column 0 when the terminal translates LF→CRLF; with that translation off, every 80 ms redraw cascaded down and to the right into scrollback. The live region now carriage-returns before every cleared row, terminates each row with CRLF, and caps each row to the terminal width so a wrapped line cannot desync the cursor-up from the logical line count. Fixed inconsistent vertical spacing between transcript blocks: some blocks (tool results from search/find and other renderer-backed tools) rendered with a doubled gap (a leading Spacer plus the content box's own paddingY), while others (the grouped read card, file-mention lists, IRC cards) rendered with no gap at all. Vertical spacing is now owned entirely by the chat renderer: TranscriptContainer strips each block's plain-blank top/bottom edges and inserts exactly one blank line between consecutive blocks, so every block is separated by a single consistent gap regardless of which component produced it. Individual components (assistant/user/tool/read-group/bash/eval/skill/custom/hook/compaction/branch/todo-reminder/plan-review messages) no longer emit their own leading Spacer/paddingY for separation, and multi-row groups (IRC cards, file-mention lists, completed-job batches, and the bordered command//changelog//context/version/OAuth/debug panels) are wrapped as single TranscriptBlock children so the renderer spaces them as one unit. Background-colored box padding is preserved as block-internal design. Fixed resolve with action: "discard" surfacing a hard isError "No pending action to resolve" failure to the model when the agent asked to cancel a staged action (e.g. an ast_edit preview) but nothing was pending. A discard is a request to reach the "no staged change" end-state, which already holds in that case, so it is now honored as a successful cancellation ("Nothing to discard; no pending action remains." with details.action: "discard") instead of an error. action: "apply" with no pending action still errors. Fixed the collapsed tool-output expand hint rendering double brackets (e.g. ((Ctrl+O for more))) — the EXPAND_HINT text already carried its own parentheses and then formatExpandHint wrapped it again with the theme's bracket glyphs. The hint now resolves the key actually bound to app.tools.expand at render time and reads ⟨: Expand⟩ (e.g. ⟨Ctrl+O: Expand⟩), so a single bracket pair surrounds it and a user remap of the expand keybinding is reflected instead of a hard-coded Ctrl+O. Fixed the edit/apply_patch tool dropping its outlined frame while streaming/in-progress (only the final result was framed); the in-progress diff preview now renders inside the same muted frame as the completed result. Fixed the todo and job tools rendering a success icon and success styling on a failed/error result; error results now show the error icon and a red frame border. Fixed debug tool refusing every dlv launch on Go modules. The launch handler ran validateLaunchProgram before adapter selection and rejected any directory program with launch program resolves to a directory, while dlv's default mode=debug requires a Go package path (a directory or .go source file). Adapter resolution now precedes validation, directory programs prefer adapters that advertise acceptsDirectoryProgram before falling back to native extensionless debuggers, the rejection only fires when the resolved adapter does not advertise that flag (set on dlv in dap/defaults.json), and dlv's mode is derived from the program shape — directories and .go files launch as mode=debug, other files as mode=exec — so omp can debug both Go packages and pre-built binaries (#2020). @oh-my-pi/pi-natives Fixed Fixed applyBashFixups corrupting commands that contain multi-byte UTF-8 before a trailing | head/| tail (or 2>&1). brush-parser reports source positions as Unicode-scalar (char) offsets, but pi_shell::fixup sliced the command &str by those numbers as if they were byte offsets, so each multi-byte char (e.g. ✓/× in a grep -E pattern) shifted the cut earlier and left a mangled command — e.g. … |✓|×|XCTAssert" | tail -80 became … |✓|×-80, orphaning the closing quote and making the shell reject the whole pipeline with unterminated double quote. Positions are now translated to byte offsets before slicing. @oh-my-pi/pi-tui Breaking Changes Removed Kitty temp-file image transmission, its startup support probe, the PI_KITTY_IMAGE_TRANSMISSION override, and the temp-file helper exports. Kitty/Ghostty image payloads now stay on in-band base64 before placeholder/direct placement, avoiding blank first renders from temp-file load races. Renamed RenderRequestOptions.allowUnknownViewportMutation → allowUnknownViewportTransientRepaint. The option only permits a transient live-viewport repaint (autocomplete/IME/focused-editor chrome) on hosts that cannot report viewport position; it never authorizes a settled transcript commit. The old name implied any offscreen mutation was safe to push into native scrollback, which led callers to emit duplicate transcript copies. Added Added TUI.addStartListener() so feature hooks can re-enable terminal modes after temporary stop/start cycles such as external-editor handoffs. Added Editor.pasteText() to apply terminal-style paste handling for text inserted from non-bracketed paste transports Added an optional dispose() lifecycle method to Component so components can release timers and subscriptions during permanent teardown Added Container.dispose() to propagate teardown to child components when a component tree is permanently discarded Added Loader.dispose() to stop the loader animation timer when the component is disposed Added a ScrollView ellipsis option (defaults to Ellipsis.Unicode) so callers that pre-wrap content to width can pass Ellipsis.Omit and suppress the stray per-line … that lands on trailing padding. Added ScrollView.handleScrollKey() plus a fastScrollLines option so every scroll view gets shared navigation keys, including Shift+Arrow to scroll faster. Added OverlayOptions.fullscreen: while the topmost visible overlay sets it, the engine borrows the terminal's alternate screen buffer for the overlay's lifetime and paints only the modal there — no ED3, no transcript re-commit — so the transcript stays untouched on the normal screen and is not scrollable behind the modal. Mouse tracking (?1000h/?1006h) is enabled for the modal's lifetime and disabled on exit, so the rest of the app keeps the terminal's native text selection. Added the submitPinsViewportToTail terminal capability and detectSubmitPinsViewportToTail(): genuine local terminals where a submit keystroke scrolls the host to its tail reconcile deferred native scrollback at the prompt-submit checkpoint even when the viewport position is unprobeable (Ghostty/kitty/iTerm/WezTerm/Alacritty). Restores the pre-regression submit reconciliation without re-enabling it for Windows Terminal/ConPTY, SSH, or multiplexers, where a submit is not proof the host is at the tail. Changed Changed static Loader messages to repaint only at the spinner's 80 ms cadence; time-dependent message colorizers can opt into 16 ms redraws with animated: true. Changed keybinding matching to precompute canonical key sets so each input sequence is parsed once per binding check instead of once per candidate key. Made Component.invalidate() optional so leaf components without render caches no longer need no-op invalidation hooks. TERMINAL is now a RuntimeTerminal whose post-construction capabilities (image protocol and the probe-driven flags) are writable, replacing the as unknown as MutableTerminalInfo cast pattern and the positional withTerminalOverrides rebuild with a prototype-preserving clone(). Fixed Fixed Loader text updates to skip identical messages and preserve the rendered Text cache instead of invalidating it every timer tick. Fixed fullscreen overlay alt-frame rendering to reuse the current line-preparation path instead of calling removed fitting helpers. Reduced TUI render-path line fitting by deferring overlay base-frame fitting until an overlay rebuild and by reusing already-fitted lines in emitters. Reduced live-region pinned repaint output by diffing unchanged viewport rows when no sealed rows are being committed to native scrollback. Fixed no-append live-region pinned repaints to re-anchor the hardware cursor when the logical viewport shifts. Fixed keybinding matching so printable uppercase input preserves Shift for bindings such as shift+a. Optimized terminal image-line detection and Thai/Lao AM normalization checks to avoid hot-path regex scans and substring allocations. Fixed Markdown.render() cache hits returning the cache's mutable backing array, which let callers that append extra rows corrupt cached Markdown and duplicate those rows on every redraw. Fixed first-paint full replays for callers that intentionally replace terminal history by allowing TUI.start({ clearScrollback: true }), so they do not briefly append an entire initial frame before the first clean replay. Fixed ED3-risk streaming cap accounting to preserve the native scrollback high-water mark for rows that were already physically committed before transient frames were viewport-capped. Fixed terminal stop and restore cleanup to disable enhanced paste mode so it does not remain enabled after shutdown Removed the per-frame line-fit Map cache from the render timer path to avoid forcing JSC rope-string hashing during scheduled viewport repaints. Fixed visibleWidth() so terminal column measurements for ANSI and OSC text now match the native truncation/wrapping helpers, including OSC 66 text-sizing spans being counted at their scaled payload width Fixed cursor, padding, and line-fit behavior when strings contain tabs or OSC escapes by aligning visibleWidth() with the native text-width model Fixed the transcript — or a re-appearing prior view such as the welcome screen — duplicating itself on terminals without a scroll-position oracle (Ghostty/kitty/iTerm/WezTerm) when a foreground tool completes by rewriting a partly-committed block, or when the transcript is reset. A non-destructive viewport repaint no longer re-paints rows that are byte-identical to what is already committed to native scrollback into the active grid; the repaint anchor is clamped to the committed-and-unchanged prefix (min(firstChanged, scrollbackHighWater)). What's Changed fix(ai): route llama.cpp parallel tool calls by item.call_id by @roboomp in #2016 fix(debug): accept directory programs for dlv and auto-select dlv mode by @roboomp in #2021 fix(ai): coerce singleton array arguments by @roboomp in #2027 Full Changelog: v15.10.0...v15.10.1

rclone v1.73.0

Fri, 30 Jan 2026 23:12:03 +0100

This is the v1.73.0 release of rclone. Full details of the changes can be found in the changelog.

rclone v1.73.1

Tue, 17 Feb 2026 19:27:21 +0100

This is the v1.73.1 release of rclone. Full details of the changes can be found in the changelog.

rclone v1.73.2

Fri, 06 Mar 2026 21:42:26 +0100

This is the v1.73.2 release of rclone. Full details of the changes can be found in the changelog.

rclone v1.73.3

Tue, 24 Mar 2026 00:00:41 +0100

This is the v1.73.3 release of rclone. Full details of the changes can be found in the changelog.

rclone v1.73.4

Wed, 08 Apr 2026 15:42:54 +0200

This is the v1.73.4 release of rclone. Full details of the changes can be found in the changelog.

rclone v1.73.5

Sun, 19 Apr 2026 14:15:18 +0200

This is the v1.73.5 release of rclone. Full details of the changes can be found in the changelog.

rclone v1.74.0

Fri, 01 May 2026 18:10:00 +0200

This is the v1.74.0 release of rclone. Full details of the changes can be found in the changelog.

rclone v1.74.1

Fri, 08 May 2026 18:11:14 +0200

This is the v1.74.1 release of rclone. Full details of the changes can be found in the changelog.

rclone v1.74.2

Sat, 23 May 2026 12:12:31 +0200

This is the v1.74.2 release of rclone. Full details of the changes can be found in the changelog.

rclone v1.74.3

Fri, 05 Jun 2026 18:29:04 +0200

This is the v1.74.3 release of rclone. Full details of the changes can be found in the changelog.

Will Kahn-Greene: Bleach 6.4.0 releases -- final release

Fri, 05 Jun 2026 15:00:00 +0200

What is it? Bleach is a Python library for sanitizing and linkifying text from untrusted sources for safe usage in HTML. Bleach v6.4.0 released! Bleach 6.4.0 includes two security fixes, a fix to tinycss2 dependency requirements, and some other things. See the changes here: https://bleach.readthedocs.io/en/latest/changes.html#version-6-4-0-june-5th-2026 Bleach v6.4.0 is the final release I haven't used Bleach on a project in years, but I still had some time to maintain it. That changed about a year ago when I got re-orged into a new role and I haven't had time to do any Bleach work since then. To recap, Bleach sits on top of html5lib which hasn't been actively maintained in years. It is dangerous to maintain Bleach in that context. We vendored html5lib so we could make adjustments to the library to keep Bleach going. This is not a sustainable approach, but it was ok for the short term. Over the years, we've talked about other options: find another library to switch to take over html5lib development fork html5lib and vendor and maintain our fork write a new HTML parser etc None of those are feasible for me. Bleach has been a solo-maintained project for a while now. The world is crazy and it's much harder to build a team of trusted maintainers now than it was (or at least, it sure feels that way). I don't see any possibility of increasing the maintenance team or passing it to someone else responsibly. Switching contexts from my regular work to Bleach is really hard. Bleach is complicated, the problem domain is complicated, and there's a lot of nuanced context. I can't just switch gears, spend 15 minutes on Bleach to do something, and then switch back to the rest of my day. I periodically get nag messages about this which are entirely valid, but there's nothing I can do about it. It doesn't feel great. Then in 2025, Emil, a long-time Bleach contributor, built justhtml which gives us an easy migration path off of Bleach. He even took the time to write a migration guide. Thoughts and statistics In 2019, when I stepped down the first time, I wrote a post on stepping down. In 2023, when I deprecated the project, I wrote a post on Bleach 6.0.0 and deprecation. From the first commit on 2010-02-18 to today's final commit on 2026-06-05, the Bleach project lasted 16 years, 3 months — 5,951 days, or about 16.29 years. There were 64 releases. There were roughly 960 commits. From 80 roughly contributors Top 3: Will Kahn-Greene: 462 James Socol: 182 Greg Guthe: 133 Roughly 5,040 lines of Python code excluding the vendored html5lib. I was maintainer from October 2015 to now--that's a little under 11 years. It feels weird to end a project that's outlived many of the Mozilla sites and Python web frameworks it was designed to protect. What happens now? This is the end of the project. Bleach. Last release. If you're still using Bleach, I think you have three options: End your project. Maybe you don't need to be maintaining your thing anymore? Use Bleach as your reason to exit and do something different with your time on Earth. Switch to the sanitizer API. Rework your project to use the sanitizer API. Spec: https://wicg.github.io/sanitizer-api/ Docs: https://developer.mozilla.org/en-US/docs/Web/API/Element/setHTML Swap Bleach out for justhtml. Emil provided a migration guide for switching from Bleach to justhtml. Good luck with whatever option you choose! Thanks! Many thanks to James who created Bleach and gave it a set of first principles that guided our choices for 16 years. Many thanks to Greg who I worked with on Bleach for a long while and maintained Bleach for several years. Working with Greg was always easy and his reviews were thoughtful and spot-on. Many thanks to Emil who was a contributor to Bleach for a long while and created justhtml providing Bleach users a migration path. Many thanks to Jonathan who, over the years, provided a lot of insight into how best to solve some of Bleach's more squirrely problems. Many thanks to Sam who was an indispensible resource on HTML parsing and sanitizing text in the context of HTML. Many thanks to all the users and contributors of Bleach! Where to go for more For more specifics on this release, see here: https://bleach.readthedocs.io/en/latest/changes.html#version-6-4-0-june-5th-2026 Documentation and quickstart here: https://bleach.readthedocs.io/en/latest/ Source code and issue tracker here: https://github.com/mozilla/bleach/

This Week In Rust: This Week in Rust 654

Wed, 03 Jun 2026 06:00:00 +0200

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions. This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR. Want TWIR in your inbox? Subscribe here. Updates from Rust Community Official Launching the Rust Foundation Maintainers Fund Project/Tooling Updates One year of Roto, the compiled scripting language for Rust xa11y: cross-platform desktop automation via native accessibility APIs halloy 2026.7 - now supports IRCv3 reply, redact, metadata, bot mode and more! Building a Native Markdown Previewer for AI-Generated Docs with Rust and WebView BPF in the agentic era Observations/Thoughts Nine Ways to Do Inheritance in Rust, a Language Without Inheritance Async Rust: deep dive into cooperative scheduling and Tokio's architecture Rust Walkthroughs ZK snarks for Rust developers: R1CS vs Plonkish vs AIR Learn Rust Closures By Building a Tiny Rule-Based Linter Learn Bevy States, Timers, and Grid Movement by Building Snake [video] RustCurious lesson 8: Generics and Monomorphization Research Counterfactuals via the Causal Monad in Rust Crate of the Week This week's crate is remyx, a framework for building TUIs on top of Ratatui. Thanks to Manuel Garcia de la Vega for the self-suggestion! Please submit your suggestions and votes for next week! Calls for Testing An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization. If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing. No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs. Let us know if you would like your feature to be tracked as a part of this list. Call for Participation; projects and speakers CFP - Projects Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started! Some of these tasks may also have mentors available, visit the task page for more information. MD Preview - Package MD Preview for Homebrew Cask OpenSlate - Test Health Check Endpoint OpenSlate - Test Login Endpoint OpenSlate - Test Notes CRUD Endpoint OpenSlate - Test Search Endpoint OpenSlate - Test Preference Endpoint If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon! CFP - Events Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker. Scientific Computing in Rust 2026| 2026-06-05 | Virtual | 2026-07-08 - 2026-07-10 If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon! Updates from the Rust Project 500 pull requests were merged in the last week Compiler expand async drops during drop elaboration offload_kernel macro expansion std::offload sharedmem Library constify Iterator-related methods and functions move IoSlice and IoSliceMut to core::io specialize Clone of array IntoIter stabilize Path::is_empty stop needing an alloca for catch_unwind Cargo diag: Add the 'cargo::default' group diag: Report summaries for unused_deps add --output-format=json to cargo doc as an unstable option add edition for scripts anytime we mutate the manifest Rustdoc avoid ICE when rendering body-less type consts correctly propagate cfgs for glob reexports deterministic sorting for doc_cfg badges fix ICE on delegated async functions optimize impl sorting separate the caches for synthetic auto trait & blanket impls Clippy add unused_async_trait_impl lint add new lint: for_unbounded_range added new lint for map_or(..., identity) redundant_pattern_match: improve suggestions faster has_arg fold all early lint passes into one statically-combined pass fold all late lint passes into one statically-combined pass memoize first_node_in_macro for consecutive queries skip disabled off-by-default doc reparses Rust-Analyzer always use crates from sysroot in proc-macro-srv enable salsa feature for syntax-bridge also consider library features internal do not fill both drop() and pin_drop() in the "fill missing members" assist fix extract variable in token tree replace range port block and loop inference from rustc try to improve completion ranking use add deref in assign instead add &mut for value kill proc-macro-srv processes on shutdown remove direct use of make constructor with editor make remove make from rename and prettify macro expansion Rust Compiler Performance Triage This week we saw nice wins across the board thanks to merging several compiler queries together (#155678), and also substantial improvements in doc performance thanks to doing less work when sorting trait impls (#157179). Triage done by @Kobzol. Revision range: 783eb8c8..4804ad7e Summary: (instructions:u) mean range count Regressions ❌ (primary) 0.3% [0.1%, 0.7%] 14 Regressions ❌ (secondary) 0.4% [0.1%, 0.9%] 39 Improvements ✅ (primary) -0.9% [-6.8%, -0.2%] 111 Improvements ✅ (secondary) -1.1% [-2.9%, -0.1%] 53 All ❌✅ (primary) -0.8% [-6.8%, 0.7%] 125 3 Regressions, 1 Improvement, 2 Mixed; 4 of them in rollups 35 artifact comparisons made in total Full report here. Approved RFCs Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: No RFCs were approved this week. Final Comment Period Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. Tracking Issues & PRs Rust Tracking Issue for strip_circumfix Tracking issue for CommandExt::show_window Tracking Issue for path_set_times Tracking Issue for nonzero_from_str_radix Tracking Issue for LoongArch CRC Intrinsics Tracking Issue for Vec::from_fn Add Step::forward/backward_overflowing to enable RangeInclusive loop optimizations Stabilize core::range::{legacy, RangeFull, RangeTo} Tracking Issue for box_as_ptr Tracking Issue for explicit-endian String::from_utf16 Reduce unreachable-code churn after todo!() make repr_transparent_non_zst_fields a hard error Tracking Issue for algebraic floating point methods riscv: promote d, e, and f target_features to CfgStableToggleUnstable Tracking Issue for PathBuf::into_string Compiler Team (MCPs only) Desugar async blocks in HIR instead of MIR Test new solver and polonius alpha on CI Add -Zllvm-target-feature target *modifier* to directly set LLVM-level target features, and deprecate doing that with -Ctarget-feature Set requirements for windows-gnu Create a new Tier 3 target: powerpc64le-unknown-none Add flag to pass MSRV/package.rust-version for use by lints Optimize repr(Rust) enums by omitting tags in more cases involving uninhabited variants. Promote tier 3 riscv32 ESP-IDF targets to tier 2 Proposal for Adapt Stack Protector for Rust Unsafe Code Guidelines Can references to uninhabited types ever be valid? No Items entered Final Comment Period this week for Rust RFCs, Cargo, Language Team, Language Reference or Leadership Council. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list. New and Updated RFCs BTF relocations --allow-unstable-flags: Allow unstable flags on stable Upcoming Events Rusty Events between 2026-06-03 - 2026-07-01 🦀 Virtual 2026-06-03 | Virtual (Indianapolis, IN, US) | Indy Rust Indy.rs - with Social Distancing 2026-06-04 | Virtual (Berlin, DE) | Rust Berlin Rust Hack and Learn 2026-06-04 | Virtual (Nürnberg, DE) | Rust Nuremberg Rust Nürnberg online 2026-06-04 | Virtual (Tel Aviv-yafo, IL) | Code Mavens 🦀 - 🐍 - 🐪 Exploring FalkorDB - Learning to use a Graph Database in Rust 2026-06-06 | Virtual (Kampala, UG) | Rust Circle Meetup Rust Circle Meetup 2026-06-07 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Rust Deep Learning: First Sunday 2026-06-08 | Virtual (Cardiff, UK) | Rust and C++ Cardiff RustWeek Reflections 2026-06-09 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Second Tuesday 2026-06-09 | Virtual (London, UK) | Women in Rust 👋 Community Catch Up 2026-06-10 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-06-16 | Virtual (Washington, DC, US) | Rust DC Mid-month Rustful 2026-06-17 | Hybrid (Vancouver, BC, CA) | Vancouver Rust Rust Study/Hack/Hang-out 2026-06-17 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-06-18 | Hybrid (Seattle, WA, US) | Seattle Rust User Group June, 2026 SRUG (Seattle Rust User Group) Meetup 2026-06-18 | Virtual (Berlin, DE) | Rust Berlin Rust Hack and Learn 2026-06-21 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Rust Deep Learning: Third Sunday 2026-06-23 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Fourth Tuesday 2026-06-23 | Virtual (London, UK) | Women in Rust Lunch & Learn: What the heck are monads - and how do we fake them in Rust 2026-07-01 | Virtual (Indianapolis, IN, US) | Indy Rust Indy.rs - with Social Distancing Africa 2026-06-09 | Johannesburg, ZA | Johannesburg Rust Meetup Rust by Example - Lifetimes Europe 2026-06-03 | Dublin, IE | Rust Dublin Join us live and INPERSON for Rust 261 2026-06-03 | Girona, ES | Rust Girona Rust Girona Hack & Learn 06 2026 2026-06-10 | München, DE | Rust Munich Rust Munich 2026 / 2 - Hacking Evening 2026-06-11 | Switzerland, CH | PostTenebrasLab Rust Meetup Geneva 2026-06-12 - 2026-06-14 | Kraków, PL | Rustmeet Rustmeet 2026-06-16 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig Interactive: Everything is Open Source 2026-06-16 | Milano, IT | Rust Language Milan Real-time planning in Rust: SolverForge & SERIO 2026-06-18 | Aarhus, DK | Rust Aarhus Talk Night at Danske Commodities 2026-06-23 | Paris, FR | Rust Paris Rust meetup #86 2026-06-25 | Berlin, DE | Rust Berlin Rust Berlin Talks: The next generation North America 2026-06-04 | Chicago, IL, US | Chicago Rust Meetup Rust Happy Hour 2026-06-04 | Saint Louis, MO, US | STL Rust Testing, Coverage, Tracey & Mutations 2026-06-06 | Boston, MA, US | Boston Rust Meetup Boston Common Rust Lunch, June 6 2026-06-11 | Lehi, UT, US | Utah Rust Utah Rust June Meetup 2026-06-11 | Mountain View, CA, US | Hacker Dojo RUST MEETUP at HACKER DOJO 2026-06-11 | San Diego, CA, US | San Diego Rust San Diego Rust June Meetup - Back in person! 2026-06-16 | San Francisco, CA, US | San Francisco Rust Study Group Rust Hacking in Person 2026-06-16 | San Francisco, CA, US | San Francisco Rust Study Group Rust Hacking in Person 2026-06-17 | Hybrid (Vancouver, BC, CA) | Vancouver Rust Rust Study/Hack/Hang-out 2026-06-18 | Hybrid (Seattle, WA, US) | Seattle Rust User Group June, 2026 SRUG (Seattle Rust User Group) Meetup 2026-06-24 | Austin, TX, US | Rust ATX Rust Lunch - Fareground 2026-06-24 | Los Angeles, CA, US | Rust Los Angeles Rust LA: Rust-Based Constraint Solvers in 2D Sketching with Zoo Technologies 2026-06-25 | Atlanta, GA, US | Rust Atlanta Rust-Atl 2026-06-26 | New York, NY, US | Rust NYC Rust NYC's Big Summer Social Oceania 2026-06-25 | Melbourne, AU | Rust Melbourne Rust Melbourne June 2026 South America 2026-06-18 | Florianópolis, BR | Rust SC Rust Floripa If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access. Jobs Please see the latest Who's Hiring thread on r/rust Quote of the Week If memory safety bugs were Waldo (Wally): finding them in C programs is a "Where's Waldo?" game, and Rust's unsafe simplifies it to "Is this Waldo?" – kornel on rust-users Thanks to Moy2010 for the suggestion! Please submit quotes and vote for next week! This Week in Rust is edited by: nellshamrell llogiq ericseppanen extrawurst U007D mariannegoldin bdillo opeolluwa bnchi KannanPalani57 tzilist Email list hosting is sponsored by The Rust Foundation Discuss on r/rust

v8.13.0

Wed, 03 Jun 2026 20:09:07 +0200

The new raised-hand indicators are now also displayed in the list of raised hands during group calls. It's a second-hand place to figure out who you should hand it over to when you're done speaking.

The Rust Programming Language Blog: Launching the Rust Foundation Maintainers Fund

Tue, 02 Jun 2026 02:00:00 +0200

If you want to financially support the development of Rust, please consider donating to the Rust Foundation Maintainers Fund. A few months ago, the Rust Foundation announced the Rust Foundation Maintainers Fund (RFMF). Since then, the Rust Project has been closely cooperating with the Rust Foundation to determine how exactly this fund will be used to support Rust maintainers. This resulted in the acceptance of RFC #3931, which established the Funding team and the Maintainer in Residence program. The primary goal of the Funding team is to ensure that maintainers who work on Rust and its toolchain will be properly supported. We will talk to Rust Project members to figure out their funding situation, meet Rust team leads to learn about their maintenance needs, approach companies to find opportunities for them to invest into Rust by supporting Rust maintainers, coordinate various funding efforts and ensure that the beneficial effects of funded maintenance are visibly promoted, with the help of the Content team. Maintainer in Residence is a new program dedicated to financially supporting existing Rust Project maintainers1. Each Maintainer in Residence will be funded to maintain one or more critical parts of Rust, such as the compiler, the standard library, Cargo, Clippy or one of many other projects that the Rust Project develops and maintains. The funded work will include activities such as performing large-scale refactorings, code reviews, unblocking new features, issue triaging, mentoring other contributors and more, and will be split between priorities guided by the teams they are supporting and priorities of their own choosing within the Project. Where applicable, Maintainers in Residence are also encouraged to propose, champion, and drive forward Rust Project Goals. The goal of this program is to provide stable and long-term funding so that maintainers can focus on important work that ensures the long-term health of Rust. The funding team will select Maintainers in Residence based on funding availability and maintenance needs within the Rust Project, and help ensure that they are successful. We expect that this will usually be a (near) full-time position, but that will depend on the nature of the work and the area of maintenance. This program extends our existing support for Rust maintainers, such as the program management program and the compiler-ops program. An important development is that we now have a centralized mechanism for gathering donations from both individuals and companies, and a dedicated team that will help direct those funds to specific maintainers. You can find more details about the funding team and the Maintainer in Residence program in the RFC. We expect to hire the first Maintainer in Residence in the upcoming months and announce it on this blog, so stay tuned! How to contribute funds If you are an individual who wants to help Rust succeed and thrive, you can donate to the RFMF through GitHub Sponsors2. Companies who would like to invest in better maintenance of Rust can also donate through GitHub Sponsors or they can contact the Rust Foundation directly. The important thing is that all proceeds from this fund will be directly used to support Rust Project maintainers. We currently expect that to happen primarily through the Maintainer in Residence program, but it can also be done in the form of smaller-scale grants or other mechanisms, as determined by the Funding team. We will figure this out on the go, as this is also quite new for us. We really appreciate each donation, however small, because with more money we can hire more maintainers to ensure that we can continue to develop Rust and that important improvements are not blocked on maintenance tasks. This is especially important at this time, where Rust is starting to get used more and more in the industry in various application areas, which increases the need for sustained maintenance. The importance of multiple funding sources is underscored by an unfortunate trend we currently observe, where key Rust maintainers are losing their funding for Rust work due to budget shifts. The Rust Foundation Maintainers Fund is designed to provide stable funding for Rust maintainers that is less dependent on sudden shifts in the job market and the IT industry. As with most things, there is no one-size-fits-all solution, so there are multiple ways to support Rust financially. The RustNL Maintainers Team recently hired several Rust Project maintainers. Previously, we wrote about how you can support specific individuals working on Rust. And there are also Rust Project Goals in search of funding. We welcome all efforts that can help support Rust Project maintainers, who often do work that is near invisible and thankless, while at the same time incredibly important and necessary, on a volunteer basis. Thank you for considering sponsoring the development and maintenance of Rust! You can find more information about funding Rust on our Funding page. This program was inspired by the Developer in Residence concept used by the Python Software Foundation (PSF), with which we led several helpful discussions. Thank you, PSF! ↩ Note that the fact that GitHub Sponsors is currently enabled on the rustfoundation GitHub organization, and not the rust-lang organization, is an implementation detail that might change in the future. All donations raised on this Sponsors page will be routed to the Rust Foundation Maintainers Fund and will be spent on directly supporting Rust Project maintainers. ↩

Tom Ritter: webgl renderer privacy

Mon, 01 Jun 2026 19:36:00 +0200

WebGL exposes the details of your graphics hardware (specifically, the string that describes the rendering engine) in 2 ways. There are three levels of protection that browsers have taken to protect this data. gl.getParameter(gl.VENDOR) and gl.getParameter(gl.RENDERER) - these are the 'simple' names. At some point in the past, someone argued that it wasn't enough information, and therefore we have a second API let ext = gl.getExtension('WEBGL_debug_renderer_info'); and then gl.getParameter(ext.UNMASKED_VENDOR_WEBGL) and gl.getParameter(ext.UNMASKED_RENDERER_WEBGL) The unmasked values are intended to be the more detailed ones, so always make sure you're comparing apples to apples. Another axis is that WebGL can render with Hardware or Software. This isn't a guarentee which one you'll get, but you can hint towards one or the other and the browser may or may not respect it. Here are your values: Alright, now let's talk about what browsers do about it. There's no point in talking about Vendor, Renderer, and Unmasked Vendor - they don't really show as much detailed info, it's all about Unmasked Renderer. There are three levels: Give a constant value. (Or don't return anything at all.) 'Round' the values into buckets Give the exact value back Safari and Tor Browser give constant values. Firefox 'rounds'. Chrome (and Brave, and I assume all-ish other Chrome-based browsers) give the exact value. Firefox actually is purusing constant values, this week. I wrote this document for our QA team to test it. (You can get a sense of the internal sausage making it takes to launch a privacy feature from it.) I don't know if you can see the dates but I made it May 20th. The problem is this - websites use this data legitimately to adjust behavior so that users get the best experience possible. I found one example where they detect a buggy graphics stack; and a couple of examples where they adjust rendering so things are more performant for users with lower end machines - a problem Apple has less to worry about because they only support certain machine models! A common response to this seems to be ambivalence, and I would suggest that is a bit elitist. Yes, if you're caring about the details reveal by a particular Web API you probably have a computer where you don't need to worry, but making the web work well for everyone is important for equitable access to improving everyone's human condition. We have been bucketing WebGL Renderer since 2021. While many of our (supported, on-by-default) fingerprinting protections are part of Enhanced Tracking Protection - rolling out first in PBM/ETP Strict before making it to ETP Standard/Normal Browsing Mode - the bucketing is on by default, for everyone, and is not disabled if ETP is disabled. How much of a difference does it make? A lot! Here is the distribution of the raw values. 83,705 distinct values. Compare that to the bucketed data. 131 distinct values. Now this data is from Firefox, so I cant say conclusively what the distribution of data is in other browsers, but... yeah. To claim Chrome (of all browsers!) is doing this better than us is pure FUD. We're making a big impact in how fingerprintable you are today and we're trying to improve it even further.

Nick Fitzgerald: A Structure-Aware Fuzzing Experiment

Mon, 01 Jun 2026 09:00:00 +0200

Structure-aware fuzzing can better exercise the system under test (SUT) by crafting inputs in the format expected by the SUT, rather than throwing pseudorandom bytes against it. That is, it avoids “shallow” inputs that the SUT will reject early (for example, syntactically invalid source text when fuzzing a programming language’s compiler) and only produces inputs that go “deep” into the SUT (e.g. programs that type-check and exercise the mid-end optimizer and backend code generator). The Rust fuzzing ecosystem is largely built around cargo-fuzz and the libfuzzer-sys crate, which provides two methods for structure-aware fuzzing: Generating structured inputs from scratch with the arbitrary crate Mutating existing inputs from the fuzzer’s corpus in a structure-aware manner, thereby producing new structured inputs, via the fuzz_mutator! hook While the two methods are not technically mutually exclusive, combining the two can be difficult and engineering resources are finite. So: If we are only implementing one approach, is generation or mutation better? To help answer this question, I implemented structure-aware generation and mutation of guaranteed-valid WebAssembly (Wasm) instruction sequences. This task is small enough to be easily understandable but large enough and real enough to (hopefully) be representative and applicable to other domains, or, at the very least, interesting.1 To evaluate their effectiveness, I used Wasmtime as the SUT, libfuzzer-sys as the fuzzing engine driving everything, and then compared code coverage over time when using mutation-based fuzzing versus generation-based fuzzing. Additionally, there are many ways we can generate pseudorandom WebAssembly instruction sequences. In this experiment, I’ve evaluated three methods: Unconstrained instruction sequence generation followed by a fixup pass to ensure validity Generating valid instructions in a forwards, bottom-up manner (from operands to operators) Generating valid instructions in a backwards, top-down manner (from operators to operands) In contrast, while there are surely many ways to mutate a given WebAssembly instruction sequence into a new, valid instruction sequence, I’ve only implemented one method: perform an arbitrary instruction insertion, deletion, or replacement, producing a new but probably-invalid instruction sequence, and then run the same fixup pass mentioned previously to ensure validity. This is the direct mutation-based equivalent of the first generation-based method. Before continuing further, I want to disclose that I am the author of wasm-smith and mutatis, and a maintainer of Wasmtime, arbitrary, libfuzzer-sys, and cargo-fuzz. That is, while I am familiar with Wasm, fuzzing, fuzzing Wasm, and both the arbitrary and mutatis crates, I may also be propagating my own biases into these implementations. Background Generation-Based and Mutation-Based Fuzzing A generation-based fuzzer uses a generator to create a pseudo-random test cases from scratch, feeds these into the system under test, and reports any failures to the user: fn generation_based_fuzzing( // A test-case generator. generator: impl Fn() -> T, // A function to run the system under test with a // generated test case, returning a result that // describes whether the run was successful or // not. run_system_under_test: impl Fn(&T) -> FuzzResult, ) { loop { // Generate an input. let input = generator(); // Run the input through the system under test. let result = run_system_under_test(&input); // If the system crashed, panicked, failed an // assertion, violated an invariant, or etc... // then report that to the user. if let Err(failure) = result { report_to_user(&input, failure); } } } On the other hand, mutation-based fuzzers are given an initial corpus of inputs and create new inputs by mutating existing corpus members. They run each new input through the SUT, report failures the same as before, and if the new input was “interesting” (for example, exercised new code paths in the SUT that weren’t previously covered in any other input’s execution) then the new input is added into the corpus for use in future test iterations: fn mutation_based_fuzzing( // A corpus of test cases. corpus: &mut Corpus, // A function to pseudo-randomly mutate an existing // input into a new input. mutate: impl Fn(&T) -> T, // A function to run an input in the system under // test, returning a result that describes whether // the run was successful or not. run_system_under_test: impl Fn(&T) -> FuzzResult, ) { loop { // Choose an old test case from the corpus. let old_input = corpus.choose_one(); // Pseudo-randomly mutate that old test case, // creating a new one. let input = mutate(old_input); // Run the input through the system under test. let result = run_system_under_test(&input); // If the system crashed, panicked, failed an // assertion, violated an invariant, or etc... // then report that to the user. if let Err(failure) = result { report_to_user(&input, failure); } // If the input was interesting, for example if // it executed previously-unknown code paths, // then add it into the corpus for use in a // future iteration. if result.input_was_interesting() { corpus.insert(input); } } } The two approaches are not mutually exclusive and hybrid generation- and mutation-based fuzzers exist. More resources: Wikipedia’s “Fuzzing” article’s “Reuse of existing input seeds” section The Fuzzing Book’s Mutation-Based Fuzzing chapter Writing a Test Case Generator for a Programming Language Structure-Aware Fuzzing Structure-unaware fuzzing will generate pseudorandom byte sequences and pass them directly to the SUT. If the SUT expects some sort of structured input, e.g. the source text for a programming language, it is likely that these byte sequences are invalid and will be rejected early by the SUT’s frontend. For example, when fuzzing a compiler, the input is rejected as syntactically invalid by the parser or rejected as semantically invalid by the type checker. This can be useful when hardening a tokenizer, parser, or type checker, but is less useful when hunting for misoptimization in the mid-end or bad instruction encoding in the backend because the inputs are unlikely to make it that far through the compiler’s pipeline. Structure-aware fuzzing will produce inputs that match the SUT’s expected input format. Returning to the compiler-fuzzing example, structure-aware fuzzing lets us generate valid programs for the compiler, so we can exercise more of the mid-end and backend, rather than just the frontend. Structure-aware fuzzing is often generation-based: for example using grammar-based fuzzing to generate pseudorandom strings from a given language grammar or language-specific tools like csmith and wasm-smith that generate C and WebAssembly programs respectively. But structure-aware fuzzing can also be mutation-based: libFuzzer’s custom mutator example implements a structure-aware mutator for zlib-compressed strings, where the raw input is decompressed, the decompressed data is mutated, and then the mutated data is recompressed to provide the new raw input. The mutator is aware of the SUT’s zlib-compressed input structure. More resources: Wikipedia’s “Fuzzing” article’s “Aware of input structure” section google/fuzzing on structure-aware fuzzing The rust-fuzz book on structure-aware fuzzing The arbitrary Crate The arbitrary crate helps Rust developers write custom structure-aware generators for fuzzing. It provides building blocks and abstractions for translating a raw byte sequence (usually from a fuzzing engine) into a structured type, effectively interpreting the raw bytes as a “DNA string” or set of predetermined choices for its decision tree. The library also provides a derive(Arbitrary) macro to automatically implement its functionality for a given type. Because arbitrary is effectively implemented by combining decision trees, it is extremely easy to create imbalanced trees and unintentionally bias the distribution of generated test cases. The mutatis Crate The mutatis crate is, at a high-level, performing the same role for authoring structure-aware mutators that arbitrary plays for generators. That is, it provides Rust developers with abstractions and combinators for creating custom structure-aware mutators. It also provides a derive(Mutate) macro to automatically implement its functionality for a given type. mutatis is designed to resist bias via a two-phase design: first, it enumerates all of the candidate mutations that could be applied to a test case, and only afterwards chooses a particular random mutation from the candidate set to actually apply. WebAssembly WebAssembly is a virtual instruction set designed to be safe, portable, and fast. It is a stack machine where an instruction’s operands are popped off a stack during execution and results pushed. It has sandboxed linear memories, global variables, and local variables (the latter two effectively being two kinds of virtual registers). The following instruction sequence computes a * 3 and stores the result into memory at address p: ;; [] local.get $p ;; [p] local.get $a ;; [p, a] i32.const 3 ;; [p, a, 3] i32.mul ;; [p, a*3] i32.store ;; [] Generator and Mutator Implementation The range of all three generators and the mutator is the same universe of WebAssembly programs. They are all implemented on top of the same Module and Inst types, and, given enough time, none is capable of producing an instruction sequence that another cannot. This helps ensure that our comparison is apples-to-apples. However, due to their different implementation techniques, they do produce different distributions of WebAssembly programs within that universe, and produce test cases at different speeds from one another, which ultimately affects how efficiently they exercise the SUT. All of the generators are built on top of the arbitrary crate. The mutator is built on top of the mutatis crate. The Module type is our structured fuzzing input. It describes a WebAssembly module containing a variable number of linear memories, a variable number and type of globals, and one function with a variable number and type of parameters and results and a variable instruction sequence: /// A WebAssembly module of the shape: /// /// (module /// (memory ...) /// (memory ...) /// ... /// /// (global ...) /// (global ...) /// ... /// /// (func (export "run") (param ...) (result ...) /// ... /// ) /// ) pub struct Module { num_memories: u32, globals: Vec, param_types: Vec, result_types: Vec, instructions: Vec, } The Inst type is an enum of all the WebAssembly instructions the implementations support, which is all of the integer, float, SIMD, memory, local, and global instructions. Control-flow, threading, table, and GC instructions are not supported. Here is a subset of Inst’s definition: /// A WebAssembly instruction. pub enum Inst { Drop, LocalGet(u32), GlobalGet(u32), // ... I32Const(i32), I32Add, I32Sub, I32Mul, // ... I64Const(i64), I64Add, I64Sub, I64Mul, // ... F32Const(f32), F32Add, F32Sub, F32Mul, // ... F64Const(f64), F64Add, F64Sub, F64Mul, // ... I32WrapI64, I64ExtendI32S, I64ExtendI32U, // ... V128Const(i128), I8x16Add, I8x16Sub, // ... I32Load(u32), I64Load(u32), // ... I32Store(u32), I64Store(u32), // ... MemorySize(u32), MemoryGrow(u32), } There is an Inst::operand_types method that returns the types that the instruction pops from the stack, and an Inst::result_type method that returns the type of the value that the instruction pushes onto the stack, if any. Finally, the Module::to_wasm_binary method encodes the module into WebAssembly’s binary format, so it can be fed into Wasmtime. These methods are used, directly or indirectly, in every generator and mutator implementation. arb The arb generator leverages derive(arbitrary::Arbitrary) on our structured input types to generate a pseudorandom instance of Module, unconstrained by validity. The module’s instruction sequence is almost certainly not valid at this point: it likely is missing operands for instructions, producing more results than the function’s signature describes, producing results of types that don’t match the function signature, accessing globals and locals that don’t exist, etc… Having produced an instance of Module, it next calls the Module::fixup method to mutate the Module so that it is valid. The fixup method works by abstractly interpreting the instruction sequence to track the types of each value on the stack at every program point. Whenever an instruction’s operand types don’t match the types on top of the stack, it generates dummy values of the correct type. When the instructions produce more values than the function’s signature proscribes, it emits drop instructions. impl Module { pub fn fixup(&mut self, mut make_value: impl FnMut() -> i64) { // ... // The fixed-up instructions. let mut fixed = Vec::with_capacity( self.instructions.len(), ); // The types on the stack at any given program // point. Similar to the Wasm spec's appendix's // validation algorithm. let mut stack: Vec = Vec::new(); for inst in mem::take(&mut self.instructions) { // Special-case `drop` because it is // polymorphic. if matches!(inst, Inst::Drop) { if stack.is_empty() { fixed.push( ValType::I32.make_const(make_value()), ); } else { stack.pop(); } fixed.push(inst); continue; } // First clamp entity indices to valid // ranges. let Some(inst) = self.fixup_inst_immediates( &mut make_value, has_mutable_global, inst, ) else { continue }; // Then make sure that the stack has // operands of the correct types for this // instruction. self.fixup_stack( &mut make_value, &mut fixed, &mut stack, &inst, ); // Finally, apply the effects to the stack. let len_operands = inst.operand_types( &self.globals, ).len(); stack.truncate(stack.len() - len_operands); stack.extend(inst.result_type( &self.param_types, &self.globals, )); fixed.push(inst); } // ... self.instructions = fixed; } fn fixup_stack( &mut self, mut make_value: impl FnMut() -> i64, fixed: &mut Vec, stack: &mut Vec, inst: &Inst, ) { let needed = inst.operand_types(&self.globals); let n = needed.len(); if stack.len() >= n { if (0..n).all(|i| { stack[stack.len() - n + i] == needed[i] }) { // All needed operands are on the stack. return; } } else { if stack.iter().enumerate().all(|(i, ty)| { *ty == needed[i] }) { // A prefix of needed operands are on the // stack; make constants for the tail that // are missing. for ty in &needed[stack.len()..] { fixed.push(ty.make_const(make_value())); stack.push(*ty); } return; } } // Otherwise, just make constants for all the // needed operands. for ty in needed { fixed.push(ty.make_const(make_value())); stack.push(*ty); } } // ... } The fixup method also makes sure that for all instructions that have an immediate referencing some entity, the referenced entity is valid. For example, for a local.get $l instruction, it ensures that local $l actually exists or else rewrites the local to one that does exist. impl Module { // ... fn fixup_inst_immediates( &mut self, mut make_value: impl FnMut() -> i64, has_mutable_global: bool, mut inst: Inst, ) -> Option { match &mut inst { Inst::LocalGet(l) => *l %= self.param_types.len() as u32, // ... Inst::I32Load(m) | Inst::I64Load(m) | Inst::F32Load(m) | Inst::F64Load(m) | Inst::V128Load(m) => { if self.num_memories == 0 { return None; } *m %= self.num_memories; } // ... _ => {} } Some(inst) } } After calling fixup, the arb generator invokes Module::to_wasm_binary to get the encoded Wasm program. bottom_up The bottom_up generator also uses abstract interpretation to track the types of values on the stack. It generates instructions in forwards order, from operands to operators. It begins with an empty stack, filters candidate instructions down to just those that would be valid given the types currently on the stack, randomly chooses one, updates the stack types accordingly, and repeats the process. This is the same approach that wasm-smith uses. After generating instructions this way, it then makes sure that the final types on the stack match the function signature’s results, similar to the end of fixup. impl Module { pub fn bottom_up(u: &mut Unstructured, ) -> Result { // ... let max_insts = u.int_in_range(1..=MAX_INSTS)?; let mut instructions = Vec::new(); let mut needed = result_types.clone(); for _ in 0..max_insts { if needed.is_empty() && u.ratio(3, 4)? { break; } // Choose a random instruction in a // top-down manner. let inst = choose_inst_top_down( u, needed.last().copied(), ¶m_types, &globals, num_memories, )?; // Pop the result type from `needed`, if // any, as it's been satisfied. let ty = inst.result_type( ¶m_types, &globals, ); if ty == needed.last().copied() { needed.pop(); } // Add operand type demands. match &inst { Inst::Drop => { // `drop` is polymorphic; choose // a random type. needed.push(u.arbitrary()?); } Inst::GlobalSet(g) => { needed.push(globals[*g as usize].ty); } _ => { needed.extend_from_slice( inst.operand_types(&globals), ); } } instructions.push(inst); } // Fill remaining needed types with // constants. for ty in needed.iter().rev() { instructions.push( ty.make_const(u.arbitrary()?), ); } // Instructions were generated backwards, so // reverse. instructions.reverse(); Ok(Module { param_types, result_types, globals, num_memories, instructions: prefix, }) } } fn choose_inst_top_down( u: &mut Unstructured

Andreas Farre: Session History Diagrams in Firefox DevTools

Mon, 01 Jun 2026 02:00:00 +0200

I’ve spent a lot of time at Mozilla working on session history, the machinery that keeps track of where you’ve been so the back and forward buttons do something sensible. It’s one of those parts of the browser that sounds simple from the outside and turns out to be anything but. Once you add iframes, nested iframes, and the subtle rules about when a navigation creates a new entry versus replacing the current one, the state you’re reasoning about gets large and hard to hold in your head. For years my main tool for understanding that state was reading code and printing things to a log. That works, but it’s slow, and it never quite shows you the shape of the thing. So I built a way to see it: a new DevTools panel in Firefox Nightly called Session History Diagrams. It lives under the Application tab, next to Service Workers and Manifest, and it draws the browser’s session history as a diagram that updates as you navigate. Jake diagrams I didn’t invent the idea of drawing this. The HTML spec already has a notation for it, called a Jake diagram after Jake Archibald, and that’s where I started. It’s a tabular notation where columns represent steps in session history, and rows represent navigables (the top-level browsing context plus any iframes). Background colors identify documents, a fresh color marking a new document loaded in that navigable, and the current step is shown in bold. It’s a genuinely useful way to capture multi-navigable interactions that are otherwise hard to describe in prose. These diagrams don’t have to be drawn by hand. Domenic Denicola, one of the HTML spec editors, built a Jake diagram generator that turns a description of a navigation sequence into a rendered diagram. That’s where I first started playing with a more dynamic approach to the visualization. The thing I missed the most was being able to build a history up step by step rather than describe a finished sequence all at once. So I wrote rejake, a small tool that draws diagrams in the same style1, but lets you construct the history one step at a time. But rejake, like the spec’s diagrams and Domenic’s generator before it, was stuck with a limitation the spec itself admits to, that they only work with a single level of nesting. That was exactly my problem. Real pages nest iframes inside iframes, and the bugs I was chasing usually lived down in that deeper nesting, precisely where the diagram stops being able to help. And however I drew them, I was still typing the history out by hand. It’s a short step from there to wanting the diagram to draw itself from the browser’s actual session history instead2. Firefox Session History Diagrams So the panel extends Jake diagrams to handle arbitrary nesting. Every column is a step in the session history. Every row is a frame, listed in pre-order from the frame tree: top-level document first, then its first iframe, then that iframe’s children, and so on. The current entry is highlighted in blue, and the diagram updates live as you navigate. The recording above is an ordinary bit of browsing, a handful of pages visited one after another. The top row tracks the page you’re actually looking at, and the current position is the one in blue. The interesting part is everything underneath that top row. Some of those pages didn’t just load a single document. They pulled in nested frames of their own, and the diagram stacks those below the page that owns them. None of that is visible in the address bar or anywhere in the page chrome, and the frames come and go as you move through the history. Normally you’d have no way of knowing they were ever there. Here you can read straight off the diagram which frames a given step carried, when each one entered, and when it dropped away again. Who else might want this I built this for myself, working on Gecko’s session history internals, where being able to watch the diagram change while reproducing a bug turns opaque state into something I can point at. But it turns out I’m not the only one who hits this wall. Plenty of people working elsewhere in Gecko, anywhere near navigation, end up reasoning about the same state, and now we all share one picture of it. If you build single-page applications, or work with the History API or Navigation API, you’ve probably run into the same kind of confusion from the other side. A push where you expected a replace, a missing history entry, an iframe that accumulated entries unexpectedly. These are hard to reason about without seeing the state directly, and that’s exactly what the diagram gives you. Session history isn’t a Firefox-specific problem either. Every engine implements the same part of the HTML spec, and Jake diagrams come from that shared spec. The panel only ever shows Firefox’s state, but the rules are the same everywhere, so if you work on another engine it can still be a useful reference for how one implementation behaves. It’s often the only practical way to surface an interoperability difference, which might be a bug in any of the engines, but stays hidden until you can actually see it. Enabling it The panel is available in Firefox today, behind a pref. It’s been there in some form since Firefox 150, growing more stable with each release. To turn it on, set devtools.application.sessionHistory.enabled to true in about:config, then reload DevTools and open Application → Session History. Since Firefox 153 it also works over remote debugging. Connect to a device from about:debugging and you can watch the session history of a page running on Android, the same as you would on the desktop. Thanks A big thanks to Nicolas Chevobbe, whose assistance was invaluable in getting the DevTools integration right. The work, including what’s still to come, is tracked in Bug 2015726. There’s a fair bit still on that list, like marking whether a step was a push or a replace, surfacing back/forward cache state, tying the diagram into the Network and Inspector panels, and more, all heading toward fuller DevTools support for Navigation and Session History. Notes Which, naturally, meant re-implementing the whole of Session History along the way. ↩ Getting nerd-sniped by Jan Jaeschke definitely contributed as well. ↩

Olivier Mehani: Optional Docker services and dependencies

Sun, 31 May 2026 13:58:49 +0200

Like many, docker and and compose have become my go-to tool to create software that can be conveniently deployed to production with a limited amount of headache. However, many tasks, and sometimes whole services, pertain only to the development side of the workflow, and need to stay there. Moreover, some tasks, such as time-consuming provisioning tasks, are only on-demand one-offs. They shouldn’t run at all most of the time, but they should slot into the dependency graph correctly when needed. tl;dr: I realised that docker compose supports profiles, which allows services to be enabled conditionally, along with the depends_on.[].required option, to ignore them when they are disabled. Profiles are also useful to package actions and triggers to run on demand, so they are not started by default. We can start with a simple setup where our long-running main service depends on an init service to perform preliminary steps. This can be setup with depends_on the compose.yaml. services: main: image: debian:latest command: "sh -c 'while : ; do echo main; sleep 10; done" depends_on: init: condition: service_completed_successfully init: image: debian:latest command: sh -c 'echo init; sleep 10' Even when run ning the main container, we get the right dependency (and delay). So far so good (though up will show the output from all containers. But what if we have another, much more time consuming, initialisation step? services: [...] opt-init: image: debian:latest command: sh -c 'echo opt-init; sleep 100' Perhaps we are lucky, and while it needs to run once, we don’t need it to run everytime (think: database setup). Docker compose can use profiles to select when services are started. It will then only be started when this profile is selected. Services without explicit profile will always be started, but any service with one or more profile listed will only get started iff that profile is selected. We can make the opt-init service part of the opt profile. We can also make the main service dependent on it, so it is started beforehand. services: main: [...] depends_on: [...] opt-init: condition: service_completed_successfully opt-init: [...] profiles: - opt This works well enough when the opt profile is specified but… Oh no! If the profile is not specified, the dependency on the opt-init isn’t resolvable, and none of the stack can spin up with just docker compose up Fortunately, this is easily solved with the required attribute of the depends_on objects. services: main: [...] opt-init: condition: service_completed_successfully required: false And that’s really all there is to it: with the right profile, the optional dependency is started in the desired order, but its absence is otherwise transparently ignored. Both docker compose up and docker compose --profile opt work as desired. Profiles afford us another useful trick: on-demand tasks not started by default. This can be handy for maintenance tasks (data cleanup, garbage collection, …) or test scripts (running test workload, sending message, …). Those are handy during development, but would not be necessary, or take a different form, in other deployments. services: [...] say-hello: image: debian:latest profiles: - hello command: echo hello depends_on: main: condition: service_started Conveniently, when explicitly running a service, it is not necessary to request a matching profile, keeping the command line lean: docker compose run say-hello. So here we are. Compose profiles allow us to control which services get started, and mark some as conditional. This, coupled with the ability to mark some depends_on rules as not required is a good way to seamlessly prevent heavy or otherwise time consuming services from starting when not needed, while retaining proper dependency ordering when enabled. For completeness, the full, final, compose.yaml looks as follow. services: main: image: debian:latest command: "sh -c 'while : ; do echo main; sleep 10; done'" depends_on: init: condition: service_completed_successfully opt-init: condition: service_completed_successfully required: false init: image: debian:latest command: sh -c 'echo init; sleep 10' opt-init: image: debian:latest profiles: - opt command: sh -c 'echo opt-init; sleep 100' say-hello: image: debian:latest profiles: - hello command: echo hello depends_on: main: condition: service_started The post Optional Docker services and dependencies first appeared on Narf.

Frederik Braun: The S in interoperability

Sun, 31 May 2026 00:00:00 +0200

This is a blog post about standards, their proliferation and the issues that may arise. My first involvement with standards was just as a reader. To better understand complicated code or unexpected behavior in a protocol. After a while, I also got involved and helped clarify certain things to ensure …

The Servo Blog: April in Servo: new Android UI, focus, forms, security fixes, and more!

Sun, 31 May 2026 02:00:00 +0200

Servo 0.2.0 contains all of the changes we landed in April, which came out to yet another record 534 commits (March: 530). For security fixes, see § Security. Note: the GitHub release is available now, but the crates.io release is not yet complete. We expect to publish it some time next week. We’ve shipped several new web platform features: (@lukewarlow, @mrobinson, #43189) (@simonwuelker, #44246) playback on OpenHarmony (@rayguo17, #43208) ‘minimum-scale’ and ‘maximum-scale’ values in (@shubhamg13, #40098, #43715) ‘color-mix()’ with any number of values (@Loirooriol, #43890) ‘&::before’ and ‘&::after’ in ‘::details-content’ (@Loirooriol, #43878) ‘revert-rule’ (@Loirooriol, #43878) ‘tab-size’ (@mrobinson, @SimonSapin, #44480) ‘text-align: match-parent’ (@TG199, #44073) new Worker() with blob URLs (@jdm, #44004) getContext("webgl") on OffscreenCanvas (@niyabits, #44159) the detail property on PerformanceMark and PerformanceMeasure (@shubhamg13, #44289, #44272) Plus a bunch of new DOM APIs: ‘selectionchange’ events on and (@TimvdLippe, #44461) StorageManager, in experimental mode (@Taym95, #43976) activeElement on Document and ShadowRoot (@mrobinson, #43861) crypto.subtle.supports() (@kkoyung, #43703) – Servo is the first major browser engine to support this! cellPadding, cellSpacing, and align properties on HTMLTableElement (@mrobinson, #43903) – previously supported in HTML only relatedTarget on ‘focus’ and ‘blur’ events (@mrobinson, #43926) transferFromImageBitmap() on ImageBitmapRenderingContext (@Messi002, #43984) Servo’s support for text in Chinese, Japanese, and Korean languages has improved, with correct wrapping in the layout engine (@SharanRP, #43744), and CJK fonts now enabled in servoshell’s browser UI on Windows, Linux, and FreeBSD (@yezhizhen, @CynthiaOketch, @nortti0, #44055, #44138, #44514). Navigating to a JSON file as the top-level document now renders the JSON with an interactive pretty-printer (@webbeef, @TimvdLippe, #43702). April was a big milestone for Servo, with some automated tests failing because they had hard-coded cookie expiry dates set to April 2016 plus ten years. Surprise! We’re still here. Here’s to the next 100 years of Servo (@jdm, #44341). This is another big update, so here’s an outline: Security Work in progress servoshell For developers Embedding API More on the web platform Performance and stability Security CryptoKey now zeroes buffers containing key material after use (@kkoyung, #44597). With only a few exceptions, you can only access DOM APIs in another document if that document is in the same origin. But if that document is in the same site with a different port number, Servo currently allows these accesses even though it shouldn’t. We’ve fixed some (but not all) of these incorrect accesses, specifically those that involve binding a Window or Location method in this document with a this from the other document (@yvt, @jdm, #28583). We’ve fixed a bug where localStorage and sessionStorage were usable in sandboxed and shared with every other sandboxed , rather than throwing SecurityError (@Taym95, #44002). We’ve fixed a bug where localStorage and sessionStorage were shared between all documents, rather than isolated using the origin of the containing document (@niyabits, #43988, #44038). We’ve fixed a bug where IndexedDB was usable in sandboxed and data: URL web workers (@Taym95, #44088). We’ve fixed a bug where pages in some IP address origins can evict cookies from other IP address origins (@officialasishkumar, #44152). Only evicting cookies was possible, not reading or writing them. We’ve fixed an out-of-bounds memory read in texImage3D() on WebGL2RenderingContext (@simartin, #44270), and fixed some undefined behaviour in servoshell’s signal handler (@Narfinger, #43891). Work in progress IndexedDB is now enabled in servoshell’s experimental mode (@arihant2math, #44245). As always, embedders can enable it with Preferences::dom_indexeddb_enabled (@arihant2math, #44245, #44283). IndexedDB now uses Servo’s new “client storage” system, which is based on the Storage Standard and will allow us to have a unified on-disk format and quota management for all web platform features that persistently store data (@gterzian, #44374, #43900). We’ve also made key range queries more efficient (@arihant2math, #39009), landed improvements to IDBDatabase, IDBObjectStore, IDBCursor, IDBKeyRange, IDBRequest, and to the handling of transactions, keys, values, and exceptions (@Taym95, #44128, #43901, #44009, #43914, #44161, #44183, #44059, #44215, #42998, #43805). We’ve made more progress on the IntersectionObserver API, under --pref dom_intersection_observer_enabled (@stevennovaryo, @jdm, #42204). We’re continuing to implement document.execCommand() for rich text editing (@TimvdLippe, #44529), under --pref dom_exec_command_enabled. This release adds support for the ‘bold’, ‘fontName’, ‘fontSize’, ‘italic’, ‘strikethrough’, and ‘underline’ commands (@TimvdLippe, @jdm, @mrobinson, #44511, #43287, #44432, #44410, #44194, #44030, #44039, #44041, #44075, #44234, #44250, #44331, #44390, #44137, #44293, #44312, #44347). All of the features above are enabled in servoshell’s experimental mode. Servo can now build a very basic accessibility tree for web contents, under --pref accessibility_enabled (@alice, @delan, @lukewarlow, #42338, #43558, #44437, #44438). This includes text runs, plus nine other non-interactive accessibility roles (@alice, @delan, #44255). We’ve also fixed a crash when reloading pages with accessibility enabled (@alice, #44473), and made accessibility tree updates more efficient (@alice, #44208). We’ve started implementing the Sanitizer API, under --pref dom_sanitizer_enabled (@kkoyung, #44198, #44290, #44335, #44421, #44452, #44481, #44585, #44594). We’ve also started implementing SharedWorker, under --pref dom_sharedworker_enabled (@Taym95, #44375, #44440). We’re working on the WakeLock API too, under --pref dom_wakelock_enabled (@TG199, @rovertrack, #43617, #44343). servoshell servoshell for Android now has a revamped browser UI, including a new history view (@espy, #43795), the apk is 30% smaller (@jschwe, #44278, #44182), and we’ve fixed the black screen bug when closing settings or switching back from another app (@yezhizhen, #44327). You can now close tabs on OpenHarmony too (@Narfinger, #42713). As for servoshell on desktop platforms, we’ve fixed some focus- and IME-related bugs (@mrobinson, #43872, #43932), and on Windows, we now install a normal shortcut without the strange behaviour of an “advertised” shortcut (@yezhizhen, #44223). For developers When using the Inspector tab in the Firefox DevTools, the Rules panel now includes declarations in ‘@layer’ rules (@arabson99, #43912). When logging expressions in the Console tab, and when hovering over symbols in the Debugger tab, you can now get more information about the contents of functions, arrays, objects, and other values (@atbrakhi, @eerii, #44172, #44173, #44022, #44233, #44196, #44181, #44064, #44023, #44164, #44369, #44262). When using the Debugger tab, you can now use the Scopes panel to inspect local and global variables (@eerii, @atbrakhi, #43792, #43791), you can now debug web worker scripts (@atbrakhi, #43981), and we’ve started implementing blackboxing, aka the Ignore source button (@freyacodes, #44142). We’ve also landed some initial support for the Style Editor tab (@rovertrack, #44517, #44462). We’re working towards re-enabling our automated DevTools tests in CI, which should make the feature more reliable (@freyacodes, #44577), and we’ve landed a small build reproducibility fix too (@jschwe, #44459). For developers of Servo itself, please note that the Cargo ‘release’ profile is no longer #[cfg(debug_assertions)] (@jschwe, @mrobinson, #44177). If you’ve been using ‘release’ as a “faster ‘debug’ with assertions” build locally, consider switching to ‘checked-release’ or ‘medium’. The pull request template has been updated (@mrobinson, #44135). ‘Testing’ and ‘Fixes’ should go at the bottom of the PR description, and ‘Testing’ is about automated tests, not how you tested the PR locally. We’ve made more progress on the new dev container, which will provide an alternative to our usual procedures for setting up a Servo build environment (@jschwe, @sagudev, #44126, #44111, #44162, #44641, #44109). Keep an eye out for that in the book! In the meantime, did you know that you can use Lix or Nix to build Servo on Linux with a lot less hassle, even if you’re not using NixOS? For now at least, head to the NixOS page in the book to learn more. We’ve also fixed a regression that made --debug-mozjs and MOZJS_FROM_SOURCE builds take much longer to complete on Linux when not using Nix (@jschwe, #44346). We’ve fixed building Servo with the ‘jitspew’ feature in mozjs, allowing you to set IONFLAGS to enable JIT logging (@simonwuelker, #44010). We’ve also fixed build issues on Windows and FreeBSD (@zhangxichang, @mrobinson, #44264, #44591). Embedding API With this second monthly release of the Servo library, we have some quick notes about API stability and semver compatibility: The ‘servo’ package follows Cargo’s rules for semver compatibility. 0.1.1 is compatible with version 0.1.0, but 0.2.0 is a breaking update. Until we integrate semver analysis into our release process, each monthly release will have a breaking version number, while non-breaking version numbers may be used for LTS updates. In general, dependencies of ‘servo’, like ‘servo-base’ and ‘servo-script’, do not use semver. Any release may include breaking changes. We’ve fixed a build failure affecting embedders with a new or updated Cargo.lock (@jschwe, #44093), and landed several other changes to help us with the Servo library release process (@jschwe, @mukilan, #43972, #44642, #43182, #43866, #44086, #43797). Breaking changes: WebView::animating now takes &self instead of self, so you can call it without cloning the handle (@JavaDerg, #44253) Servo::site_data_manager now returns &SiteDataManager instead of Ref

curl up 2026 summary

Thu, 28 May 2026 17:25:02 +0200

Getting curl developers and related enthusiasts into a single room to hang out in the real world for a whole weekend once a year is awesome. We find inspiration, we share experiences, we learn from each other and we dream and plan of future endeavors and things to work on. Seeing faces, hearing voices and … Continue reading curl up 2026 summary →

This Week In Rust: This Week in Rust 653

Wed, 27 May 2026 06:00:00 +0200

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions. This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR. Want TWIR in your inbox? Subscribe here. Updates from Rust Community Newsletters Scientific Computing in Rust #18 (May 2026) Project/Tooling Updates gitoxide - May 26 hyper User Survey 2025 Results Rust Update: gRPC Welcomes Tonic! serde-const-default v0.1: Removes boilerplate when using const values as field defaults BoquilaHUB 0.5: AIs for Nature. Now it includes SOTA AI bioacoustics models and embeddings models splog: a log viewer TUI with automatic tag categorization rgx v0.12.3 — Building a regex debugger for the terminal in Rust UI tests are the guardrails an AI needs: the story of clipboardwire slintcn 0.22: shadcn/ui-style copy-paste components for Slint native apps Releasing dtact v0.2.2 and rssn-advanced v0.1.0: the next generation async concurrent engine and scientific computing engine Observations/Thoughts Noroboto: Lying Fonts and Mitigation in Rust Erasing Existentials libwce: the entropy layer of a wavelet codec, on its own Tech Notes: Theseus: translating win32 to wasm Bevy Game Engine Explained Visually The reflex of deriving serde traits Physical AI Needs a Typed World Model, Not a Vector DB Keep calm and use (Rust) monorepos [audio] Rust for Linux Live with Alice Ryhl and Greg Kroah-Hartman [audio] Netstack.FM episode 38 — Building and testing network stacks with Rama [video] Can a QR code be made of stars? Rust Walkthroughs Rust Patterns & Engineering How-Tos Laissez-Faire Errors Learn Rust HashMap and Iterators by Building a Git Object Store Reader Learn the Basics of Bevy by Building and Deploying Pong to Itch.io The Slowdown That Doesn't Show Up in Profiles Building an AsyncIO executor for the 3DS [video] Nine Ways to do Inheritance in Rust, a Language without Inheritance Miscellaneous Content-addressed Rust builds (or, what kache actually caches) Crate of the Week This week's crate is inline_tweak, a crate to embed tweakable constants inside your Rust application without full recompilation. Thanks to Kill The Mule for the suggestion! Please submit your suggestions and votes for next week! Calls for Testing An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization. If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing. No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs. Let us know if you would like your feature to be tracked as a part of this list. Call for Participation; projects and speakers CFP - Projects Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started! Some of these tasks may also have mentors available, visit the task page for more information. rust cookbook - Expand Command Line section with clap derive, subcommands, and env vars If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon! CFP - Events Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker. No Calls for papers or presentations were submitted this week. If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon! Updates from the Rust Project 352 pull requests were merged in the last week Compiler rustc_on_unimplemented: introduce format specifiers account for proc macro spans in do_not_recommend diagnostics implement fast path for derive(PartialOrd) when deriving Ord make bitset would_modify_words more vectorzer-friendly parse mut restrictions stop needing materialized places for most intrinsics Library add unstable Share trait stabilize bool_to_result use strongly typed wrapped indices in VecDeque Cargo compiler: forward verbose flag to rustc for local crates don't use the network for a publish dry-run test break out RegistryConfig and crate_url for interpreting RegistryConfig::dl fix CVE-2026-5222 and CVE-2026-5223 artifact: remove compat mode from artifacts Rustdoc stabilize --remap-path-prefix in rustdoc Clippy useless_format: fire on wrapped in a block-producing macro return can be removed from the last stmt of a block if it has an expr add check for midpoint using multiplication by 0.5 and >> 1 avoid unnecessary String allocations in MinifyingSugg arithmetic ops extend clippy::missing_safety_doc to unsafe fields fix manual_range_contains NAN handling fix error message for useless_borrows_in_formatting for mutable borrows move unnecessary_get_then_check to complexity simplify is_some() && …unwrap() to is_some_and in unit_arg Rust-Analyzer diagnostics: mut_ref binding feature diagnostic assists/add_reference_here: _modify_ the reference type when dealing with &T->&mut T cfg: correct separator index in CfgDiff disable loop hir-ty: saturate float-to-uint cast in const eval test-utils: drain inactive_regions by inactive_line_region add diagnostic for E0033 add diagnostic for E0608 completions imports exclude supports sub items filter package-scoped features extract_module missing import for macro calls add type_match score for struct_pat allow wildcard params in foreign fn declarations analysis expected ty in enum variant autoimport enum variants do not autoref in method probe in path mode do not complete semicolon in match-expr place do not consider the path of the macro in a macro call to be inside a macro call emit diagnostic for rest array patterns without fixed-length arrays fix SyntaxContext::roots technically overlapping valid interneds flip coerce_never type_mismatch tys have a specific error for unimplemented builtin macros no suggest ref match when expected generic ref no use sad pattern on happy arm with guard normalize expected tuple struct pat field refactor handling of generic params in hir::Type support named consts in range pattern types use grouped annotation for add_label_to_loop provide better incrementality for modules Rust Compiler Performance Triage This week was largely positive, with most of the improvements coming from algorithm change in visibility checking: #156228. Triage done by @panstromek. Revision range: 281c97c3..783eb8c8 Summary: (instructions:u) mean range count Regressions ❌ (primary) 0.4% [0.1%, 0.7%] 5 Regressions ❌ (secondary) 0.5% [0.1%, 1.1%] 16 Improvements ✅ (primary) -0.9% [-6.6%, -0.1%] 164 Improvements ✅ (secondary) -0.4% [-1.3%, -0.1%] 51 All ❌✅ (primary) -0.9% [-6.6%, 0.7%] 169 2 Regressions, 2 Improvements, 5 Mixed; 2 of them in rollups 34 artifact comparisons made in total Full report here Approved RFCs Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: Propose the concept of a crates.io username for identity Final Comment Period Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. Tracking Issues & PRs Compiler Team (MCPs only) Promotes 5 Thumb-mode bare-metal Arm targets to Tier 2 Add -Z dead-fn-elimination to skip codegen of BFS-unreachable functions Rust Update transmute_copy to ub_checks and ?Sized Tracking Issue for NEON dot product intrinsics Never break between empty parens Rust RFCs Avoid linting unreachable_code on todo!() Unsafe Code Guidelines What are the values of a union type? (in particular, what is the validity invariant of a union) No Items entered Final Comment Period this week for Cargo, Language Team, Language Reference or Leadership Council. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list. New and Updated RFCs No New or Updated RFCs were created this week. Upcoming Events Rusty Events between 2026-05-27 - 2026-06-24 🦀 Virtual 2026-05-27 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-06-02 | Virtual | libp2p Events rust-libp2p Open Maintainers Call 2026-06-02 | Virtual (Tel Aviv-yafo, IL) | Rust 🦀 TLV ‎שיחה חופשית ווירטואלית על ראסט 2026-06-03 | Virtual (Indianapolis, IN, US) | Indy Rust Indy.rs - with Social Distancing 2026-06-04 | Virtual (Berlin, DE) | Rust Berlin Rust Hack and Learn 2026-06-04 | Virtual (Nürnberg, DE) | Rust Nuremberg Rust Nürnberg online 2026-06-04 | Virtual (Tel Aviv-yafo, IL) | Code Mavens 🦀 - 🐍 - 🐪 Exploring FalkorDB - Learning to use a Graph Database in Rust 2026-06-06 | Virtual (Kampala, UG) | Rust Circle Meetup Rust Circle Meetup 2026-06-07 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Rust Deep Learning: First Sunday 2026-06-09 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Second Tuesday 2026-06-10 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-06-16 | Virtual (Washington, DC, US) | Rust DC Mid-month Rustful 2026-06-17 | Hybrid (Vancouver, BC, CA) | Vancouver Rust Jiff 2026-06-17 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-06-18 | Hybrid (Seattle, WA, US) | Seattle Rust User Group June, 2026 SRUG (Seattle Rust User Group) Meetup 2026-06-18 | Virtual (Berlin, DE) | Rust Berlin Rust Hack and Learn 2026-06-21 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Rust Deep Learning: Third Sunday 2026-06-23 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Fourth Tuesday 2026-06-23 | Virtual (London, UK) | Women in Rust Lunch & Learn: What the heck are monads - and how do we fake them in Rust Asia 2026-06-02 | Beijing, CN | Voice AI and Rust Meetup (Rust for AI, lowcoderust.com) AI Agents and Open Source LLM (Call for Speakers) Europe 2026-05-28 | Copenhagen, DK | Copenhagen Rust Community Rust meetup #68 2026-05-28 | London, UK | Rust London User Group LDN Talks May Community Showcase 2026-05-29 | Berlin, DE | Rust Berlin Rust Berlin Talks: The next generation 2026-05-30 | Stockholm, SE | Stockholm Rust Ferris' Fika Forum #26 2026-06-02 | Frankfurt, DE | Rust Rhein-Main gRPC with Rust and Tonic 2026-06-03 | Dublin, IE | Rust Dublin Join us live and INPERSON for Rust 261 2026-06-03 | Girona, ES | Rust Girona Rust Girona Hack & Learn 06 2026 2026-06-10 | München, DE | Rust Munich Rust Munich 2026 / 2 - Hacking Evening 2026-06-11 | Switzerland, CH | PostTenebrasLab Rust Meetup Geneva 2026-06-12 - 2026-06-14 | Kraków, PL | Rustmeet Rustmeet 2026-06-16 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig Interactive: Everything is Open Source 2026-06-16 | Milano, IT | Rust Language Milan Real-time planning in Rust: SolverForge & SERIO 2026-06-18 | Aarhus, DK | Rust Aarhus Talk Night at Danske Commodities North America 2026-05-27 | Austin, TX, US | Rust ATX Rust Lunch - Fareground 2026-05-28 | Atlanta, GA, US | Rust Atlanta Rust-Atl 2026-05-28 | Los Angeles, CA, US | Rust Los Angeles Rust LA: Rust in Embedded & Autonomous Systems at Parallel Systems in DTLA 2026-05-28 | Mountain View, CA, US | Hacker Dojo RUST MEETUP at HACKER DOJO 2026-05-30 | Boston, MA, US | Boston Rust Meetup Central Cambridge Rust Lunch, May 30 2026-06-04 | Saint Louis, MO, US | STL Rust Testing, Coverage, Tracey & Mutations 2026-06-06 | Boston, MA, US | Boston Rust Meetup Boston Common Rust Lunch, June 6 2026-06-11 | Lehi, UT, US | Utah Rust Utah Rust June Meetup 2026-06-11 | Mountain View, CA, US | Hacker Dojo RUST MEETUP at HACKER DOJO 2026-06-11 | San Diego, CA, US | San Diego Rust San Diego Rust June Meetup - Back in person! 2026-06-16 | San Francisco, CA, US | San Francisco Rust Study Group Rust Hacking in Person 2026-06-17 | Hybrid (Vancouver, BC, CA) | Vancouver Rust Jiff 2026-06-18 | Hybrid (Seattle, WA, US) | Seattle Rust User Group June, 2026 SRUG (Seattle Rust User Group) Meetup 2026-06-24 | Austin, TX, US | Rust ATX Rust Lunch - Fareground 2026-06-24 | Los Angeles, CA, US | Rust Los Angeles Rust LA: Rust-Based Constraint Solvers in 2D Sketching with Zoo Technologies South America 2026-06-18 | Florianópolis, BR | Rust SC Rust Floripa If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access. Jobs Please see the latest Who's Hiring thread on r/rust Quote of the Week This overflows the trait solver today as well as my brain – Nadrieril on their blog Thanks to Theemathas for the suggestion! Please submit quotes and vote for next week! This Week in Rust is edited by: nellshamrell llogiq ericseppanen extrawurst U007D mariannegoldin bdillo opeolluwa bnchi KannanPalani57 tzilist Email list hosting is sponsored by The Rust Foundation Discuss on r/rust

Firefox Tooling Announcements: New Deploy of PerfCompare (May 27th)

Wed, 27 May 2026 23:29:33 +0200

The latest version of PerfCompare is now live! Check out the change-log below to see the updates: [kala-moz]: Bug 2036968: Replaced fast-kde with fftkde and used bootstrap-ci to get CI summary (#1034) Bug 1931291: Created expand all rows functionality (#1037) Bug 2032246: Add cles statement to expanded row (#1033) Bug 2037551: Reduced the size of perfcompare hero on Results Page (#1036) [padenot]: Use SJ bandwidth for top-level results, ISJ for subtests [shtrom]: Bug 2014041: add support for landoInstance QueryString parameter (#1038) Thank you for the contributions! Bugs or feature requests can be filed on Bugzilla. The team can also be found on the #perfcompare channel on Element. Come and chat! 1 post - 1 participant Read full topic

v8.13.0-beta.1

Thu, 28 May 2026 00:05:12 +0200

The new raised-hand indicators are now also displayed in the list of raised hands during group calls. It's a second-hand place to figure out who you should hand it over to when you're done speaking.

v8.12.0

Wed, 27 May 2026 20:29:16 +0200

On the one hand, you can click on the raise hand icon during group calls. But on the other hand, now you can use a new keyboard shortcut too (Shift-H).

Firefox Tooling Announcements: Firefox Profiler Deployment (May 26, 2026)

Tue, 26 May 2026 17:53:32 +0200

The latest version of the Firefox Profiler is now live! Check out the full changelog below to see what’s changed: Highlights: [Markus Stange] Use @streamparser/json if the input is too large to fit in a V8 string (#6016) [Nazım Can Altınova] Include --search option in pq filter push (#6026) [fatadel] Translate URL track-index state through profile sanitization (#6000) [Nazım Can Altınova] Print also the status output right after cli load command (#6019) Other Changes: [fatadel] Remove unused dependencies from package.json (#6010) [Nazım Can Altınova] Make profiler-cli work in sandboxed environments (#6003) [Markus Stange] Make profiler-edit run profile compacting before writing out the file (#6015) [Markus Stange] Migrate from prettier to oxfmt (#5986) [Markus Stange] Add a --symbolicate-wasm arg to profiler-edit. (#6008) [Markus Stange] Build and upload the cli artifact in PRs (#6020) [Nicolas Chevobbe] Update devtools-reps to 0.27.7 (#6030) [Markus Stange/fatadel] Make withSize use a wrapper element so that it can stop calling findDOMNode (#5988) [Markus Stange] Fix dhat importer (#6036) [Nazım Can Altınova] Annotate inlined frames in CLI call trees and stacks (#6041) [Nazım Can Altınova] Use proper types in cli tests instead of custom inline types (#6038) [Nazım Can Altınova] Fix text truncation for frames named after Object.prototype methods (#6044) [Nazım Can Altınova] Add missing key props to CodeErrorOverlay error list items (#6047) [depfu[bot]] Update oxfmt to version 0.51.0 (#6054) [Nazım Can Altınova] Sync: l10n → main (May 26, 2026) (#6058) [Nazım Can Altınova] Use URL-state symbol server for profiler-cli function annotate (#6051) [Nazım Can Altınova] Bump profiler-cli version to 0.2.0 (#6059) Big thanks to our amazing localizers for making this release possible: fr: YD sr: Марко Костић (Marko Kostić) tr: Ali Demirtaş zh-CN: Olvcpr423 zh-CN: wxie Find out more about the Firefox Profiler on profiler.firefox.com! If you have any questions, join the discussion on our Matrix channel! 1 post - 1 participant Read full topic

Andrew Halberstadt: Your Job is to Integrate

Tue, 26 May 2026 15:50:00 +0200

You felt it. The shift. That your role has fundamentally changed thanks to LLMs. It first entered your subconscious when you realized how easily you can now crank out PRs. You felt it more concretely (and less enthusiastically), as a reviewer when you opened your laptop one morning and noticed your review queue was double what it normally is thanks to everyone else cranking out PRs. And you feel this pervasive, general sense of friction. It’s difficult to pinpoint exactly where this friction is coming from. Depending on the repository size and CI setup, it will be slightly different for everyone. It might involve longer review times or slipping review standards. You might be noticing more merge conflicts and merge related CI failures. Perhaps there are more failures sneaking through to main or CI is taking longer to give you results. You almost certainly feel the grind. People are on edge, tired; developers are pulling in opposite directions. Here’s what LLMs shifted. The bottleneck is no longer producing code. The bottleneck is integrating it. The friction we’re feeling is a result of more PRs, more ideas, more reviews, more disagreements all made possible thanks to LLMs. In short, the problem can best be summarized by Figure 1: But we’re living in a moment where many folks haven’t realized this yet, and are still under the impression that their job is to produce code. It’s not. Your new job is to integrate it.

Mozilla Open Policy & Advocacy Blog: Growing darkness: Against the rise of internet shutdowns

Tue, 26 May 2026 10:04:08 +0200

Disruptions to internet connectivity can occur in countless ways – from weather incidents, natural disasters and accidents to intentional interferences like cyberattacks and government-issued blackouts. Yet while some disruptions are unavoidable, deliberate shutdowns represent a fundamentally different and deeply concerning trend. They undermine the open, global nature of the internet and put the safety, security, and fundamental rights of millions at risk. For over 25 years, Mozilla has worked to ensure that the internet remains a global public resource—open, accessible, and safe for all. This vision, grounded in the Mozilla Manifesto, holds that the internet must remain a shared, decentralized infrastructure that empowers individuals, supports civic participation, and enables economic opportunity. Internet shutdowns run counter to these principles by restricting access, concentrating control, and weakening the very foundations of the open web. To help organizations study and document outages, Mozilla makes aggregated Firefox telemetry data available to help identify and understand connectivity disruptions. As 2026 progresses, this data continues to show significant outages affecting millions of people worldwide—many of them the result of deliberate restrictions. As of late May, Iran’s internet blackout had been in place for over 80 days, making it the longest shutdown since the Arab Spring. Following an earlier shutdown amid nationwide protests in January 2026, Iranian authorities have restricted access to the internet since 28 February. This has meant that, for almost three months, millions of Iranians have been cut off from news, communication, work, education, and basic services. It also means that almost no independent information about the situation in Iran is leaving the country, making it almost impossible for humanitarian organizations to assess the situation on the ground. The shutdown has also had a massive impact on the Iranian economy, severely disrupting financial activity and blocking international transactions. Although Iran’s president has recently ordered an end to the shutdown, it is unclear how and when Iranians will be able to reconnect to the web. When large numbers of Firefox users experience connection failures for any reason, this produces an anomaly in the recorded telemetry data. At the country or city level, this can provide a corroborative signal of whether an outage or intentional shutdown occurred. Our telemetry documents the magnitude of the latest outage in Iran. The graph below documents the effect of the outage in multiple ways, such as users’ country location, language and timezone. Across the globe, governments are increasingly interfering with and limiting access to connectivity. Both the number of states limiting connectivity and the amount of internet shutdowns has been growing steadily. In 2025 alone, 313 shutdowns across 52 countries have been documented, a sad record. This is a stark indication that shutdowns and restrictions are no longer a rare emergency measure, but established levers of control. While the triggers for shutdowns are varied, access to the internet continues to be blocked especially often in times of conflict and political unrest. Especially in the context of hostilities, political tensions or public health emergencies, access to connectivity is a basic humanitarian need. Beyond their immediate human impact, blackouts also affect the internet itself. Local networks depend on each other to form the global internet, and local restrictions affect the resilience and reliability of the web at large. When governments deliberately disrupt connectivity, they do not only isolate populations; they also contribute to the fragmentation of the global internet, undermining trust, interoperability, and the stability of shared infrastructure. Over time, this erosion risks replacing a single, open web with a patchwork of disconnected or controlled networks. Governments should foster the health of the internet, not erode it. Access to the internet is widely recognized as essential for enjoying human rights. It is an integral part of modern life, facilitating education, communication, collaboration, business and entertainment. Preserving the open web requires sustained commitment: resisting shutdowns, promoting transparency, and reinforcing the technical and governance frameworks that keep the internet global, interoperable, and accessible. The internet’s value—as a platform for opportunity, innovation, and human connection—depends on it remaining open to all. The post Growing darkness: Against the rise of internet shutdowns appeared first on Open Policy & Advocacy.

The pressure

Tue, 26 May 2026 08:01:39 +0200

I’m doing Open Source primarily because I love it. The social aspects, the for-the-good angle and for the challenge of engineering this to work for everyone. I also do it because it is my full-time job and getting food on the table and provide for my family is not unimportant. It may come as a … Continue reading The pressure →

Mozilla Data YouTube Channel: Data Club: Jeff Silverman - Data Science & Astronomy: AAS 243 & ATDS 6

Sun, 24 May 2026 05:48:57 +0200

Jonathan Almeida: Auto-resolve Jujutsu conflicts with your AI agent

Mon, 25 May 2026 02:00:00 +0200

With Jujutsu, I've been able to work in multiple workstreams more efficiently than before. This means that if I'm working on multiple things, there is a higher likelihood of something going stale while I wait for a review or touch multiple files. Dealing with conflicts aren't so bad these days, however if I can automate the easy ones, why not? This is the prompt I've been using with my agent whenever I have a list of changes that have conflicts and don't need me to participate actively on it. Using the jj version control system, fix the conflicts that are in the changesets from `` to ``. Keep trying until there are no more "(conflict)" in the changesets between those two IDs.

Mozilla Data YouTube Channel: Introducing Glean Annotations

Sun, 24 May 2026 04:56:33 +0200

Leif Oines and Will Lachance introduce Glean Annotations: a process and technology for curating and communicating knowledge about the data we collect in Mozilla's products.

Mozilla Data YouTube Channel: Monitoring Sensitive Data: How do we monitor data we don't store?

Thu, 21 May 2026 20:30:49 +0200

We try to be responsible with data. For example, we: - store as little sensitive data as possible - monitor changes in incoming data on which we've built models But what happens when those two approaches conflict? How do we monitor changes in incoming data that we don't want to store? This talk explains the schema we use to monitor changes in what people are searching for in Firefox...even when we deliberately don't store some of what people are searching for.

Mozilla Data YouTube Channel: Mozillians sharing the 2021 SciPy Conference experience

Wed, 20 May 2026 23:10:21 +0200

The 2021 SciPy conference (https://www.scipy2021.scipy.org/) involved the showcasing of the latest open source Python projects for advancement in scientific computing. Mozilla was a diversity sponsor and a few Mozillians attended and shared their experience of the event.

Mozilla and Adafruit bring Web Serial workflows to Firefox

Thu, 21 May 2026 20:00:38 +0200

Launching Web Serial in Firefox 151 The web is built by communities, but not all communities use the web the same way. That philosophy shaped part of this week’s Firefox 151 release, which introduced support for the Web Serial API on desktop. Most folks won’t use this API, but for our community of builders and […] The post Mozilla and Adafruit bring Web Serial workflows to Firefox appeared first on The Mozilla Blog.

Designing Firefox for the future

Thu, 21 May 2026 14:55:53 +0200

Crafted with care. Built for speed. Ready for what’s next. A great browser is so intuitive that you often forget you’re using it. Yet today the internet is changing faster than ever, and your browser needs to keep up. Firefox is still the only browser built for people, not platforms: independent, customizable, private and firmly […] The post Designing Firefox for the future appeared first on The Mozilla Blog.

This Week In Rust: This Week in Rust 652

Wed, 20 May 2026 06:00:00 +0200

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions. This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR. Want TWIR in your inbox? Subscribe here. Updates from Rust Community Official Project goals update — April 2026 (end of 2025H2) Program management update — April 2026 Newsletters This Month in Rust OSDev: April 2026 Project/Tooling Updates Tonic is joining the gRPC project Toasty 0.6.0 - What is new? ex_ratatui: Elixir bindings for ratatui via Rustler NIFs OmniScope: A Cross-Language LLVM IR Static Analyzer Targeting Unsafe/FFI Boundaries: citum: a new Rust citation processor and associated tools. cargo-crap: Finding Untested Complexity in AI-Generated Rust Code What the Graph Owes: Connectors That Drive Outputs swpui: a TUI for case-aware search and replace kache 0.3.0: zero-copy efficient worktree compilation ghr: a Rust TUI for managing GitHub pull requests, issues, notifications, and reviews Observations/Thoughts Scaling Rust codebases: Lessons learned organizing large projects and managing errors Migrating from Go to Rust Why I built wrkflw [video] Rust's God Mode [video] How Rust engineered the perfect async runtime Rust Walkthroughs 5× faster fast_blur in image-rs Finding the Time Part 2 - Rust Async and the Arm Generic Timer Parsing Godot .tres files and walking the resource graph Rust x GBA: Setup and Pixels Learn Rust Lifetimes by Building a Generic LRU Cache How to benchmark Rust code with Gungraun Book: An Introduction to Programming, using ECS & EBP in Rust Crate of the Week This week's crate is cargo-crap, a cargo subcommand to calculate the Change Risk Anti-Patterns metric for a crate. Despite a lamentable lack of suggestions, llogiq is pleased with his choice. Please submit your suggestions and votes for next week! Calls for Testing An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization. If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing. No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs. Let us know if you would like your feature to be tracked as a part of this list. Call for Participation; projects and speakers CFP - Projects Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started! Some of these tasks may also have mentors available, visit the task page for more information. If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon! CFP - Events Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker. Scientific Computing in Rust 2026| 2026-06-05 | Virtual | 2026-07-08 - 2026-07-10 If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon! Updates from the Rust Project 369 pull requests were merged in the last week Compiler add Swift function call ABI implement pinned drop sugar Library map_try_insert changes implement OsStr::split_at implement into_array for Vec move std::io::Cursor to core::io move std::io::util to core::io widen the result of widening_mul Cargo clean: respect build.target config for clean -p diag: Consolidate verify/run diagnostics passes diag: Report deferred diagnostics like other diagnostics diag: Pull in the parse pass lints: Avoid compiling where possible drop -Zunstable-options for rustdoc --emit Rustdoc stabilize --emit flag correctly handle associated items in rustdoc macro expansion correctness & perf improvements to link-to-definition properly support macros with multiple kinds Clippy fix duration_suboptimal_units for small literals fix arithmetic side effects false positive Rust-Analyzer add diagnostic for E0029 add diagnostic for E0614 add diagnostic for E0638 add handler for E0040 encode the name instead of index in EnumVariantId fix assist qualify_path loses path segment add param on result methods for replace_method_eager_lazy complete ref_match in macro fully support pattern types handle usages in macro for extract_function no complete module colons before exists colons no lint unsized adt self_ty missing bounded assoc not complete same name inherent deref methods only ref match non-unknown value items show Run lens for fn main in bench targets handle TyKind::{Pat,UnsafeBinder} in has_drop_glue implement pattern_type macro method-resolution: emit error for method calls with illegal Sized bound migrate inline_call assist to SyntaxFactory perf: provide access to RootDatabase's LineIndex for the proc macro protocol show const in the signature help if applicable show unsafe in the signature help if applicable Rust Compiler Performance Triage Fewer than usual PRs merged, mostly due to a shorter week than normal and some CI trouble. Overall a slightly positive week for performance. Triage done by @simulacrum. Revision range: 29b75901..281c97c3 0 Regressions, 0 Improvements, 4 Mixed; 1 of them in rollups 17 artifact comparisons made in total Full report here Approved RFCs Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: Cargo RFC for min publish age Final Comment Period Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. Tracking Issues & PRs Compiler Team (MCPs only) Removing the unstable ptx linker flavor Create a new Tier 3 target: powerpc64le-unknown-none Optimize repr(Rust) enums by omitting tags in more cases involving uninhabited variants. Proposal for a dedicated test suite for the parallel frontend Promote tier 3 riscv32 ESP-IDF targets to tier 2 Proposal for Adapt Stack Protector for Rust No Items entered Final Comment Period this week for Rust, Rust RFCs, Cargo, Language Team, Language Reference, Leadership Council or Unsafe Code Guidelines. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list. New and Updated RFCs Documentation interpolation Upcoming Events Rusty Events between 2026-05-20 - 2026-06-17 🦀 Virtual 2026-05-20 | Hybrid (Vancouver, BC, CA) | Vancouver Rust Mouse Control with Rust 2026-05-20 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-05-21 | Hybrid (Seattle, WA, US) | Seattle Rust User Group May, 2026 SRUG (Seattle Rust User Group) Meetup 2026-05-21 | Virtual (Berlin, DE) | Rust Berlin Rust Hack and Learn 2026-05-21 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup Tock OS Part #4 - Capsule coding in QEMU! 2026-05-26 | Virtual (Cardiff, GB) | Rust and C++ Cardiff Hybrid event with Rust Dortmund! 2026-05-26 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Fourth Tuesday 2026-05-26 | Virtual (London, UK) | Women in Rust Lunch & Learn: Seeing Into Your Code - A Practical Guide to Tracing in Rust 2026-05-27 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-06-02 | Virtual | libp2p Events rust-libp2p Open Maintainers Call 2026-06-03 | Virtual (Indianapolis, IN, US) | Indy Rust Indy.rs - with Social Distancing 2026-06-04 | Virtual (Berlin, DE) | Rust Berlin Rust Hack and Learn 2026-06-04 | Virtual (Nürnberg, DE) | Rust Nuremberg Rust Nürnberg online 2026-06-07 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Rust Deep Learning: First Sunday 2026-06-09 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Second Tuesday 2026-06-10 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-06-16 | Virtual (Washington, DC, US) | Rust DC Mid-month Rustful 2026-06-02 | Virtual | libp2p Events rust-libp2p Open Maintainers Call 2026-06-17 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-06-17 | Virtual (Vancouver, BC, CA) | Vancouver Rust Rust Study/Hack/Hang-out Asia 2026-06-02 | Beijing, CN | Voice AI and Rust Meetup (Rust for AI, lowcoderust.com) AI Agents and Open Source LLM (Call for Speakers) Europe 2026-05-18 - 2026-05-23 | Utrecht, NL | RustWeek 2026 RustWeek 2026 2026-05-21 | Amsterdam, NL | RustNL RustWeek Hackathon 2026-05-22 | Amsterdam, NL | RustNL Walking Tour around Utrecht 2026-05-22 | Amsterdam, NL | RustNL Bike tour around Utrecht 2026-05-26 | Dortmund, DE | Rust Dortmund Rust Dortmund Meetup - Agentic Programming - May 2026-05-26 | Manchester, UK | Rust Manchester Rust Manchester May Code Night 2026-05-26 | Trondheim, NO | Rust Trondheim Motorized blinds, and replacing Docker, in Rust! 2026-05-28 | London, UK | Rust London User Group LDN Talks May Community Showcase 2026-05-29 | Berlin, DE | Rust Berlin Rust Berlin Talks: The next generation 2026-06-03 | Dublin, IE | Rust Dublin Join us live and INPERSON for Rust 261 2026-06-03 | Girona, ES | Rust Girona Rust Girona Hack & Learn 06 2026 2026-06-11 | Switzerland, CH | PostTenebrasLab Rust Meetup Geneva 2026-06-16 | Leipzig, SN, DE | Rust - Modern Systems Programming in Leipzig Interactive: Everything is Open Source North America 2026-05-20 | Hybrid (Vancouver, BC, CA) | Vancouver Rust Mouse Control with Rust 2026-05-20 | San Francisco, CA, US | Bay Area Rust Meetup Bay Area Rust Meetup 2026-05-21 | Hybrid (Seattle, WA, US) | Seattle Rust User Group May, 2026 SRUG (Seattle Rust User Group) Meetup 2026-05-21 | New York, NY, US | Rust NYC Rust NYC: "Boring File Storage" & "Indie News Feed Optimization" 2026-05-21 | Nashville, TN, US | Music City Rust Developers Community Meetup 2026-05-23 | Boston, MA, US | Boston Rust Meetup Allston Rust Lunch, May 23 2026-05-27 | Austin, TX, US | Rust ATX Rust Lunch - Fareground 2026-05-28 | Atlanta, GA, US | Rust Atlanta Rust-Atl 2026-05-28 | Los Angeles, CA, US | Rust Los Angeles Rust LA: Rust in Embedded & Autonomous Systems at Parallel Systems in DTLA 2026-05-28 | Mountain View, CA, US | Hacker Dojo RUST MEETUP at HACKER DOJO 2026-05-30 | Boston, MA, US | Boston Rust Meetup Central Cambridge Rust Lunch, May 30 2026-06-04 | Saint Louis, MO, US | STL Rust Testing, Coverage, Tracey & Mutations 2026-06-06 | Boston, MA, US | Boston Rust Meetup Boston Common Rust Lunch, June 6 2026-06-11 | Lehi, UT, US | Utah Rust Utah Rust June Meetup 2026-06-11 | San Diego, CA, US | San Diego Rust San Diego Rust June Meetup - Back in person! 2026-06-16 | San Francisco, CA, US | San Francisco Rust Study Group Rust Hacking in Person Oceania 2026-05-26 | Barton, ACT, AU | Canberra Rust User Group May Meetup If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access. Jobs Please see the latest Who's Hiring thread on r/rust Quote of the Week Posts like this are useful for those of us who like to help, and who work on rustc to make it more helpful, by letting us learn about what kinds of mistakes people make. – Kevin Reid on rust-users Thanks to firebits.io for the suggestion! Please submit quotes and vote for next week! This Week in Rust is edited by: nellshamrell llogiq ericseppanen extrawurst U007D mariannegoldin bdillo opeolluwa bnchi KannanPalani57 tzilist Email list hosting is sponsored by The Rust Foundation Discuss on r/rust

v8.12.0-beta.1

Wed, 20 May 2026 23:03:11 +0200

On the one hand, you can click on the raise hand icon during group calls. But on the other hand, now you can use a new keyboard shortcut too (Shift-H).

Spidermonkey Development Blog: Saying goodbye to asm.js

Wed, 20 May 2026 13:56:51 +0200

Axe-time, sword-time, shields are sundered, Wind-time, wolf-time, ere the world falls. – Völuspá, Poetic Edda As of Firefox 148, SpiderMonkey’s asm.js optimizations are disabled by default, and we plan to remove the code entirely in a future release. If you maintain a site that uses asm.js, nothing will break. asm.js is just a subset of plain JavaScript, so the code keeps running through our regular JIT just like any other script. That said, recompiling to WebAssembly will get you faster execution and smaller binaries. History asm.js was Mozilla’s response to the question posed by NaCl and PNaCl: how can the web run code at native speeds? The idea was clever: pick a strict, statically-typed subset of JavaScript that an engine could recognize on the fly and compile down to native code. We could get performance similar to NaCl/PNaCl and still have code live inside web content and use web API’s (no separate sandbox, IPC, or alternative API’s). asm.js shipped in Firefox 22 back in 2013 and was a success. It let projects like Unity and Unreal ship C/C++ codebases to the web for the first time, using just standard web technologies. The Epic Citadel demo was ported to the web in just four days. It was a landmark achievement, and a fond memory for the original asm.js team. asm.js proved that we could run code at near-native speed on the web using just web technologies. This opened the door to WebAssembly, which shipped several years later in Firefox 52. Without asm.js, we likely wouldn’t have WebAssembly. Why now? So why turn it off? WebAssembly has succeeded, and asm.js usage has mostly migrated over. Keeping the asm.js path alongside WebAssembly costs us maintenance time and gives us extra attack surface in the VM. If you are shipping asm.js content, please consider recompiling to WebAssembly! Our WebAssembly pipeline is significantly more advanced than the asm.js one ever was. You should see faster execution and smaller binaries. Ragnarök The asm.js compiler is called OdinMonkey. As was foretold long ago, OdinMonkey must meet his fated doom. The bug Ragnarök tracks the “Twilight of OdinMonkey”. All is not lost however, for born of OdinMonkey is BaldrMonkey, our WebAssembly optimizing compiler. OdinMonkey may be swallowed whole by the wolf, Fenrir, but BaldrMonkey will rule over the reborn world alongside RabaldrMonkey (“commotion”), our WebAssembly baseline compiler. On this Odin’s day (Wednesday) we thank OdinMonkey for thirteen years of service. Skål! Then fields unsowed bear ripened fruit, all ills grow better, and Baldr comes back; Baldr and Hoth dwell in Hropt’s battle-hall. – Völuspá, Poetic Edda

Firefox Developer Experience: Firefox WebDriver Newsletter 151

Tue, 19 May 2026 16:00:00 +0200

WebDriver is a remote control interface that enables introspection and control of user agents. As such, it can help developers to verify that their websites are working and performing well with all major browsers. The protocol is standardized by the W3C and consists of two separate specifications: WebDriver classic (HTTP) and the new WebDriver BiDi (Bi-Directional). This newsletter gives an overview of the work we’ve done as part of the Firefox 151 release cycle. Contributions Firefox is an open source project, and we are always happy to receive external code contributions to our WebDriver implementation. We want to give special thanks to everyone who filed issues, bugs and submitted patches. In Firefox 151, Armin Ulrich contributed a fix to WebDriver BiDi: Removed an unused helper from our MessageHandler codebase. WebDriver code is written in JavaScript, Python, and Rust so any web developer can contribute! Read how to setup the work environment and check the list of mentored issues for Marionette, or the list of mentored JavaScript bugs for WebDriver BiDi. Join our chatroom if you need any help to get started! General Added support for altitudeAngle and azimuthAngle to pointer actions of subtype touch. These properties allow simulating touch interactions with precise angular orientation data, specifying the angle at which a pointer contacts a surface and its rotational direction. Fixed a bug where UnknownError DOM exceptions originating from content pages were incorrectly treated as internal WebDriver errors. WebDriver BiDi Implemented the browser.setClientWindowState command. This command allows clients to change the OS-level window state of a browser window, such as maximized, minimized, fullscreen, or normal. It also allows repositioning and resizing the window. Added support for worker realms (for dedicated, shared and service workers) in the script.getRealms command. The command now returns realm information for worker scripts in addition to window contexts. Included the top-most stack frame in log.entryAdded events for all Console API messages. Improved the text field of the log.entryAdded event to better align with Firefox DevTools behavior and Google Chrome WebDriver BiDi implementation. Fixed network event cookies to include all properties, not just name and value. Fixed the network.getData command timing out for redirects. Fixed the browsingContext.reload command not resetting the location of a navigated iframe. Removed the empty proxy capability from the session.new command response when no proxy is specified. Marionette Enabled browser window repositioning on Linux Wayland in headless mode.

AI controls are here for Firefox mobile

Tue, 19 May 2026 18:01:58 +0200

Mobile browsing is personal. It’s the link you open from a group chat because someone said, “Wait, is this real?” It’s the article you read in the few quiet minutes you have to yourself. It’s the review you skim before buying something you’ve been thinking about all week. On a phone, browsing follows you through […] The post AI controls are here for Firefox mobile appeared first on The Mozilla Blog.

New in Firefox 151: VPN location selection, AI controls on mobile, and expanded Shake to Summarize support

Tue, 19 May 2026 18:06:59 +0200

Today, Firefox is rolling out updates across desktop and mobile that give you more choice over how you browse. Here’s a look at what’s new. Adding location selection to Firefox’s free VPN Firefox now offers a fully featured VPN experience directly in the browser — for free. In just two months, over 1 million users […] The post New in Firefox 151: VPN location selection, AI controls on mobile, and expanded Shake to Summarize support appeared first on The Mozilla Blog.

Firefox’s Shake to Summarize expands to Android and new languages on iOS

Tue, 19 May 2026 09:00:27 +0200

Don’t let bloated websites slow you down. When you just need the gist, scrolling through ads and filler content can turn a quick check into an endless scroll. Firefox’s Shake to Summarize feature solves that. We first launched it on iOS in English last September, earning a special mention in TIME’s Best Inventions of 2025 […] The post Firefox’s Shake to Summarize expands to Android and new languages on iOS appeared first on The Mozilla Blog.

named globs with curl

Sat, 16 May 2026 22:58:26 +0200

One of the established power features of the curl command line tool is its support for “globbing”. It is a built-in way to specify ranges and sets in different ways and have curl iterate over them to simplify repeated transfers. For example, you can easily download three images from the same host without having to … Continue reading named globs with curl →

Mozilla Privacy Blog: Mozilla to UK regulators: VPNs are essential privacy and security tools and should not be undermined

Fri, 15 May 2026 14:23:31 +0200

In the context of concerns around young people’s interactions with digital technologies, the UK’s Department for Science, Innovation and Technology is consulting on additional measures to prepare young people for growing up in a digital world. Before the backdrop of users circumventing age assurance systems mandated under the UK’s Online Safety Act, the consultation considers age-gating virtual private networks (VPNs). Mozilla’s mission is grounded in the belief that the internet must remain open and accessible to all, and that privacy and security online are fundamental human rights. We recognize that the protection of young people online is one of the most pressing and challenging questions of our time, and we are committed to supporting policy proposals that address the root causes of online harms. We are concerned, however, that blunt interventions like mandatory age assurance and restricting access to tools like VPNs are not effective in improving the protection afforded to young people online, while undermining the fundamental rights of all users. VPNs serve as critical privacy and security tools for users across all ages. By hiding users’ IP addresses, VPNs help protect users’ location, reduce tracking and avoid IP-based profiling. People use VPNs for lots of different reasons: to connect to their school’s or employer’s network remotely, to avoid censorship or to simply protect their privacy and security online. While being able to access VPNs is especially important for vulnerable groups like activists, dissidents or journalists, VPNs improve everyone’s baseline protection online. Young people are particularly vulnerable to online tracking, targeted advertising, and the risks that flow from personal data being collected and processed for commercial purposes without adequate consent or transparency. In a world in which young people are interacting with digital technologies as part of their realities from young ages onward, restricting young people’s access to privacy-protecting technologies is in tension with the goal of equipping them to navigate the internet safely and competently. In order to be able to develop agency and responsible habits in engaging with digital technologies, it is crucial for young people to be introduced to best practices and key safety and privacy tools as they engage with the online world. Rather than age-gating technologies like VPNs, we believe that regulators should address the root causes of online harm by holding platforms to account, encouraging the responsible use of parental controls and investing in digital skills and a whole of society approach to digital wellbeing. Read our full submission to the Department for Science, Innovation and Technology. The post Mozilla to UK regulators: VPNs are essential privacy and security tools and should not be undermined appeared first on Open Policy & Advocacy.

v8.11.0-beta.1

Thu, 14 May 2026 21:11:02 +0200

We've introduced additional confirmations and educational messaging in the app to help protect Signal users from phishing and social engineering attacks. As a reminder, never reply to chats pretending to be Signal, and never send your verification code, PIN, or recovery key to anyone. Raised hand indicators in group calls now display the current order of the queue, so you can easily see who got the upper hand first. We also added a real-time visualization while recording voice messages, so surfers (and oceanographers) can stare at multiple moving waveforms whenever they share updates from the beach.

This Week In Rust: This Week in Rust 651

Wed, 13 May 2026 06:00:00 +0200

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions. This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR. Want TWIR in your inbox? Subscribe here. Updates from Rust Community Foundation Rust Foundation and Package Registry Leaders Unite to Address Open Source Sustainability Crisis Newsletters The Embedded Rustacean Issue #71 Project/Tooling Updates Numax - A portable Rust runtime for distributed apps Entroly 0.18.0: Rust-powered AI context engine with PRISM reinforcement learning, SimHash dedup, and EGSC caching uFerris: A Versatile Learning Board for Rust Embedded Record Ownership: Which Side Is Right? iroh 1.0.0-rc.0 - The first release candidate Burn 0.21.0 Release: Up to 8× Lower Framework Overhead, Differentiable Collectives and Improved Kernels Ratty: A terminal emulator with inline 3D graphics Announcing the Rust runtime for Appwrite Functions Announcing diesel-async 0.9 Fresh 0.3.4: Ansi-native 'terminal' theme matches the system's theme; UI for Live Grep + custom grep providers; persistent 'dock' split; Verilog/VHDL support; and much more Observations/Thoughts Killing a Cow made my JSON formatter 42% faster Getting Started with Geospatial Rust — What satellites measure, spectral bands, indices, cloud detection. Lessons Learned Building High-Performance Rust Profiler The limits of Rust, or why you should probably not follow Amazon, Cloudflare and Discord The hidden cost of mpsc channels "Respectful" YAML patching in Rust Rust Walkthroughs Learn Rust Generics and Traits By Building a Mini Blackjack Game Build a Full-Featured Text Editor From Scratch | 0xKiire Where the sun keeps shinin': the provider pattern End-to-End Geospatial Processing with EORST — Build a satellite pipeline in Rust: STAC query to GeoTIFF. All the ways to mock your Rust code Rust in Android Development: Complete Guide Miscellaneous Announcing the 2026 Rust-Edu Refresh and CFP Crate of the Week This week's crate is cloakrs, a library and CLI tool for detecting and masking personally identifiable information. Despite having no suggestion to work with, llogiq is content with his choice. Please submit your suggestions and votes for next week! Calls for Testing An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization. If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing. No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs. Let us know if you would like your feature to be tracked as a part of this list. Call for Participation; projects and speakers CFP - Projects Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started! Some of these tasks may also have mentors available, visit the task page for more information. No Calls for participation were submitted this week. If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon! CFP - Events Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker. Scientific Computing in Rust 2026| 2026-06-05 | Virtual | 2026-07-08 - 2026-07-10 If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon! Updates from the Rust Project 502 pull requests were merged in the last week Compiler consider Result and ControlFlow to be equivalent to T for must use lint fewer global node_id_to_def_id lookups introduce move expressions (move($expr)) resolve: evaluate private visibilities eagerly in eff vis computation Library add Command::get_resolved_envs add Drop::pin_drop for pinned drops add keepalive, set_keepalive to TcpStream implementations drop unmapped ZSTs in array map have arrays' drop_glue just unsize and call the slice version implemented PathBuf::into_string Cargo diag: Track Cargo diagnostic warning/error count like is done for rustc suggest 'fmt' when user types 'cargo rustfmt' rebuild when -Zpublic-dependency changes Clippy add new lint inline_trait_bounds new lint: manual_clear fix manual_option_zip false positive when the outer param is used in closure incompatibility of non_canonical_clone_impl and implicit_return Rust-Analyzer add wrap in tree list with editor add diagnostic for E0436 add diagnostic for E0529 complete :: on module def support deref patterns add whitespaces on postfix completion in macro do not infer signatures, instead infer anon consts in them do not replace closure capture place types with errors if they fail to normalize fix handling of self in lower_coroutine_body_with_moved_arguments() fix offer on unrelated for toggle_macro_delimiter generally fix derive helper resolution in semantics in "Implement missing members", do not add assoc types with defaults no add spaces on ..= on macro inside macro provide an InferCtxt to TyLoweringContext provide source map for the lowered let self = self binding in async fns ref match uses unified type renaming mut vars removed mut in patterns generated by macro respect lint attributes for diagnostics that don't set their main node remove make mut Rust Compiler Performance Triage This week saw a couple of PRs affecting the new trait solver, which is steadily moving forward, in particular #156139 was a massive perf. win. #156185 optimized visibility computation, resulting in up to a 8% win on the typenum crate. Triage done by @Kobzol. Revision range: 1d72d7e8..aa31d6d8 Summary: (instructions:u) mean range count Regressions ❌ (primary) 0.3% [0.1%, 0.4%] 62 Regressions ❌ (secondary) 0.5% [0.1%, 1.5%] 77 Improvements ✅ (primary) -1.7% [-8.8%, -0.2%] 18 Improvements ✅ (secondary) -13.6% [-85.6%, -0.0%] 34 All ❌✅ (primary) -0.2% [-8.8%, 0.4%] 80 2 Regressions, 2 Improvements, 5 Mixed; 4 of them in rollups 31 artifact comparisons made in total Full report here. Approved RFCs Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: Rust Foundation Maintainer Fund RFC: Inheriting of default-features in Cargo Final Comment Period Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. Tracking Issues & PRs Rust lint on core::ffi::c_void as a return type Tracking issue for release notes of #154647: change c_double to f32 on avr targets Stabilize --remap-path-prefix in rustdoc Replace printables table with unicode_data.rs tables Tracking issue for RFC 2137: Support defining C-compatible variadic functions in Rust (c_variadic Tracking Issue for Path::is_empty Tracking Issue for integer formatting into a fixed-size buffer resolve: Partially convert ambiguous_glob_imports lint into a hard error Rust RFCs Propose the concept of a crates.io username for identity Cargo RFC for min publish age Language Reference New rule layout.repr.c.struct.align-empty Leadership Council Establish the funding team No Items entered Final Comment Period this week for Cargo, Compiler Team (MCPs only), Language Team or Unsafe Code Guidelines. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list. New and Updated RFCs No New or Updated RFCs were created this week. Upcoming Events Rusty Events between 2026-05-13 - 2026-06-10 🦀 Virtual 2026-05-17 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Rust Deep Learning: Third Sunday 2026-05-19 | Virtual (Washington, DC, US) | Rust DC Mid-month Rustful 2026-05-20 | Hybrid (Vancouver, BC, CA) | Vancouver Rust Mouse Control with Rust 2026-05-20 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-05-21 | Hybrid (Seattle, WA, US) | Seattle Rust User Group May, 2026 SRUG (Seattle Rust User Group) Meetup 2026-05-21 | Virtual (Berlin, DE) | Rust Berlin Rust Hack and Learn 2026-05-21 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup Tock OS Part #4 - Capsule coding in QEMU! 2026-05-26 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Fourth Tuesday 2026-05-26 | Virtual (London, UK) | Women in Rust Lunch & Learn: Seeing Into Your Code - A Practical Guide to Tracing in Rust 2026-05-27 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-06-03 | Virtual (Indianapolis, IN, US) | Indy Rust Indy.rs - with Social Distancing 2026-06-04 | Virtual (Berlin, DE) | Rust Berlin Rust Hack and Learn 2026-06-04 | Virtual (Nürnberg, DE) | Rust Nuremberg Rust Nürnberg online 2026-06-07 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Rust Deep Learning: First Sunday 2026-06-09 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Second Tuesday 2026-06-10 | Virtual (Girona, ES) | Rust Girona Weekly coding session Asia 2026-05-13 | Malaysia, MY | Rust Meetup Malaysia Rust Meetup May 2026 2026-05-14 | Seoul, KR | Seoul Rust (Programming Language) Meetup Seoul Rust Meetup 2026-05-16 | Bangalore, IN | Rust Bangalore May 2026 Rustacean meetup 2026-06-02 | Beijing, CN | Voice AI and Rust Meetup (Rust for AI, lowcoderust.com) AI Agents and Open Source LLM (Call for Speakers) Europe 2026-05-13 | Girona, ES | Rust Girona Rust Girona Hack & Learn 05 2026 2026-05-14 | Switzerland, CH | PostTenebrasLab Rust Meetup Geneva 2026-05-18 - 2026-05-23 | Utrecht, NL | RustWeek 2026 RustWeek 2026 2026-05-18 | Milano, MI, IT | Rust Language Milan RustWeek 2026 2026-05-19 | Aarhus, DK | Rust Aarhus Hack Night 2026-05-19 | Amsterdam, NL | RustNL RustWeek 2026 announcement 2026-05-19 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig Cross-Building & Cross-Testing 2026-05-19 | London, UK | Women in Rust RustWeek lunch meetup 2026-05-21 | Amsterdam, NL | RustNL RustWeek Hackathon 2026-05-22 | Amsterdam, NL | RustNL Bike tour around Utrecht 2026-05-26 | Dortmund, DE | Rust Dortmund Rust Dortmund Meetup - Agentic Programming - May 2026-05-26 | Manchester, UK | Rust Manchester Rust Manchester May Code Night 2026-05-29 | Berlin, DE | Rust Berlin Rust Berlin Talks: The next generation 2026-06-03 | Dublin, IE | Rust Dublin Join us live and INPERSON for Rust 261 North America 2026-05-14 | Lehi, UT, US | Utah Rust Utah Rust May Meetup 2026-05-14 | Mountain View, CA, US | Hacker Dojo RUST MEETUP at HACKER DOJO 2026-05-14 | Portland, OR, US | PDXRust From Radio Waves to Pixels - Real-Time Visualizations with Rust and WebAssembly 2026-05-14 | San Diego, CA, US | San Diego Rust San Diego Rust May Meetup - Back in person! 2026-05-16 | Boston, MA, US | Boston Rust Meetup Lechmere Rust Lunch, May 16 2026-05-19 | San Francisco, CA, US | San Francisco Rust Study Group Rust Hacking in Person 2026-05-20 | Hybrid (Vancouver, BC, CA) | Vancouver Rust Mouse Control with Rust 2026-05-20 | San Francisco, CA, US | Bay Area Rust Meetup Bay Area Rust Meetup 2026-05-21 | Hybrid (Seattle, WA, US) | Seattle Rust User Group May, 2026 SRUG (Seattle Rust User Group) Meetup 2026-05-21 | Nashville, TN, US | Music City Rust Developers Community Meetup 2026-05-23 | Boston, MA, US | Boston Rust Meetup Allston Rust Lunch, May 23 2026-05-27 | Austin, TX, US | Rust ATX Rust Lunch - Fareground 2026-05-28 | Atlanta, GA, US | Rust Atlanta Rust-Atl 2026-05-28 | Los Angeles, CA, US | Rust Los Angeles Rust LA: Rust in Embedded & Autonomous Systems at Parallel Systems in DTLA 2026-05-30 | Boston, MA, US | Boston Rust Meetup Central Cambridge Rust Lunch, May 30 2026-06-04 | Saint Louis, MO, US | STL Rust Testing, Coverage, Tracey & Mutations 2026-06-06 | Boston, MA, US | Boston Rust Meetup Boston Common Rust Lunch, June 6 Oceania 2026-05-14 | Melbourne, AU | Rust Melbourne Rust Melbourne - May 2026 2026-05-26 | Barton, ACT, AU | Canberra Rust User Group May Meetup South America 2026-05-13 | Montevideo, UY | Rust Meetup Uruguay Rust Uruguay meetup de Mayo If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access. Jobs Please see the latest Who's Hiring thread on r/rust Quote of the Week Of the last 150 merged PRs to Bun, 108 are memory-safety-adjacent — missed cleanup on an error path, use-after-free, uninitialized reads, out-of-bounds access, reentrancy. 75 of those would not compile in a language with destructors, move semantics, and a borrow checker. One in three PRs we ship is "forgot to free something on an error path." Of the 108, ~88 are in Zig. The ~14 in C++ are mostly ref-cycles and GC-concurrency races — the residual class that survives any language. So the Zig→Rust delta is real: the Zig bugs are exactly the destructor/ownership-fixable kind, and the C++ side is already near the floor. Without stronger compile-time guarantees, this stays a cat-and-mouse game. The proposal is to remove the largest bug class structurally rather than fix instances of it indefinitely. – Jarred Sumner on the bun github Thanks to Brian Kung for the suggestion! Please submit quotes and vote for next week! This Week in Rust is edited by: nellshamrell llogiq ericseppanen extrawurst U007D mariannegoldin bdillo opeolluwa bnchi KannanPalani57 tzilist Email list hosting is sponsored by The Rust Foundation Discuss on r/rust

Firefox Tooling Announcements: MozPhab 2.15.1 Released

Wed, 13 May 2026 22:14:01 +0200

Bugs resolved in Moz-Phab 2.15.1: bug 2036719 moz-phab --no-stack doesn’t work as suggested? Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix. 1 post - 1 participant Read full topic

One hundred curl graphs

Sun, 15 Mar 2026 11:42:45 +0100

In the spring of 2020 I decided to finally do something about the lack of visualizations for how the curl project is performing, development wise. How does the line of code growth look like? How many command line options have we had over time and how many people have done more than 10 commits per … Continue reading One hundred curl graphs →

bye bye RTMP

Sat, 21 Mar 2026 15:06:12 +0100

In May 2010 we merged support for the RTMP protocol suite into curl, in our desire to support the world’s internet transfer protocols. RTMP The protocol is an example of the spirit of an earlier web: back when we still thought we would have different transfer protocols for different purposes. Before HTTP(S) truly became the … Continue reading bye bye RTMP →

NTLM and SMB go opt-in

Sun, 22 Mar 2026 12:41:09 +0100

The NTLM authentication method was always a beast. It is a proprietary protocol designed by Microsoft which was reverse engineered a long time ago. That effort resulted in the online documentation that I based the curl implementation on back in 2003. I then also wrote the NTLM code for wget while at it. NTLM broke … Continue reading NTLM and SMB go opt-in →

One hundred weirdo emails

Wed, 25 Mar 2026 09:05:41 +0100

I hope I don’t have to spell it out but I will do it anyway: in these cases I don’t know anything about their products and I cannot help them. Quite often I first need to search around only to figure out what the product is or does, that the person asks me about. Over … Continue reading One hundred weirdo emails →

Don’t trust, verify

Thu, 26 Mar 2026 11:09:07 +0100

Software and digital security should rely on verification, rather than trust. I want to strongly encourage more users and consumers of software to verify curl. And ideally require that you could do at least this level of verification of other software components in your dependency chains. Attacks are omnipresent With every source code commit and … Continue reading Don’t trust, verify →

High-Quality Chaos

Wed, 22 Apr 2026 13:44:40 +0200

As I have been preparing slides for my coming talk at foss-north on April 28, 2026 I figured I could take the opportunity and share a glimpse of the current reality here on my blog. The high quality chaos era, as I call it. No more AI slop I complained and I complained about the … Continue reading High-Quality Chaos →

curl 8.20.0

Wed, 29 Apr 2026 08:27:01 +0200

You always find the new curl releases on the curl site! Release presentation Numbers the 274th release8 changes49 days (total: 10,761)282 bugfixes (total: 13,922)521 commits (total: 38,545)0 new public libcurl function (total: 100)0 new curl_easy_setopt() option (total: 308)0 new curl command line option (total: 273)73 contributors, 45 new (total: 3,664)28 authors, 12 new (total: 1,463)8 … Continue reading curl 8.20.0 →

Inspired

Thu, 30 Apr 2026 08:49:47 +0200

In appendix A of the book Root cause: Stories and lessons from two decades of Backend Engineering Bugs, author Hussein Nasser has these wonderful words to say about me: Daniel Stenberg is a Swedish engineer and the creator of curl (cURL), one of the most widely used tools and libraries for fetching content over various … Continue reading Inspired →

Approaching zero bugs?

Thu, 30 Apr 2026 10:08:34 +0200

In this era of powerful tools to find software bugs, we now see tools find a lot of problems at a high speed. This causes problems for developers, as dealing with the growing list of issues is hard. It may take a longer time to address the problems than to find them – not to … Continue reading Approaching zero bugs? →

Mythos finds a curl vulnerability

Mon, 11 May 2026 08:01:35 +0200

yes, as in singular one. Back in April 2026 Anthropic caused a lot of media noise when they concluded that their new AI model Mythos is dangerously good at finding security flaws in source code. Apparently Mythos was so good at this that Anthropic would not release this model to the public yet but instead … Continue reading Mythos finds a curl vulnerability →

Mozilla Privacy Blog: Six Million Selections Later: How the DMA Is Giving People Browser Choice

Mon, 11 May 2026 21:03:25 +0200

At Mozilla, we’ve long believed in giving people choice and agency over their experiences online. As power in digital markets has concentrated in a small number of large companies, there have been efforts in the US, Japan, UK, India, Korea, Brazil and elsewhere to restore competition and put choice back in people’s hands. These efforts are at various stages, but first among them was the EU’s Digital Markets Act. Over two years since obligations came into effect, the DMA is delivering for people in some key areas. Not everywhere. Not perfectly. And not without enforcement. But browser choice is the clearest example. Every 10 seconds, someone picks Firefox through a DMA choice screen Operating systems like iOS, Android, Windows, and MacOS lean on pre-installed browsers, tricky default settings, and deceptive design to make it hard for people to exercise choice and to keep independent browsers from competing on a level playing field. But where the DMA has created opportunities for genuine browser choice, people are taking it. New Mozilla data is clear: since the rules took effect, Firefox is selected through a DMA browser choice screen every 10 seconds. That adds up to more than six million Firefox selections. And people are sticking with us: retention is five times higher when people choose Firefox through a choice screen. Academic analysis points the same way. Independent researchers compared Firefox daily active users in the EU with 43 non-EU countries. Comparing the 15 months before and after browser choice screens rolled out on iOS, they found that Firefox daily active users (DAU) were 113% higher in the EU than it would have been without the DMA. On Android, it was 12% higher. The smaller Android effect is due to the fact that Firefox usage there started from a much higher base, and the Android rollout has been more uneven than on iOS. The research also shows that the DMA’s effect is growing over time. Browser choice on mobile is moving, but desktop is left behind The DMA’s work isn’t done. There remains room for improvement on mobile (including making it easier to import your data to a new browser and switch with one click). However, desktop remains largely untouched – leaving roughly 310 million desktops and laptops in the EU without equivalent browser choice. For example, Windows users are subject to deceptive design tactics and are not given an active choice. Even where choice screens exist, they are not a silver bullet; ecosystem lock-in and interoperability barriers still hold back competition and innovation. Still, the signal is clear: when people get real browser choice, they take it and select alternatives. It’s easy for gatekeepers to dismiss this as a couple of competitors benefiting. This ignores the range of challenger browsers also reporting huge growth in the EU. What’s more, it ignores the benefit to people. DMA browser choice screens are reaching different audiences. Mozilla analysis shows that women make up a significantly higher share of Firefox selections on iOS via a choice screen than organic downloads, suggesting that choice screens may successfully reach a demographic that reports lower confidence in manually changing browser defaults. The DMA’s effects are only starting to be felt and understood. The road ahead Effective enforcement of the obligations is the way forward. Gatekeepers continue to test and, in many instances, openly push back against the intent of the DMA provisions. This can take the form of implementation choices that limit real user uptake, delays in rolling out effective solutions, or sustained efforts to reinterpret, weaken, or roll back key provisions. Most evidently, privacy and security arguments are often elevated in ways that risk diverting attention from whether compliance is delivering genuine choice and competition in practice. In reality, privacy, security, and effective competition can and should be designed to work hand-in-hand. They do not always have to be traded off. Policymakers and enforcers should remain focused on outcomes: ensuring that the DMA delivers real-world competition and user choice, and resisting efforts to dilute its impact through partial compliance or narrative reframing. Browser choice is just the start Mozilla’s hope is that real browser choice will become the rule, rather than the exception. And that the lessons of browser choice screens will be applied to other areas of the DMA, including data portability and interoperability. Only with full compliance – including applying the existing DMA text to AI – can the full benefits of competition and innovation be brought to people in the EU. The post Six Million Selections Later: How the DMA Is Giving People Browser Choice appeared first on Open Policy & Advocacy.

Who will pioneer the next web?

Mon, 26 Jan 2026 20:14:14 +0100

Who will build the next version of the web? Mozilla wants to make it more likely that it’s you. We are committing time and resources to bring experienced builders into Mozilla for a short, programmed period, to work with our New Products leaders to build tools and products for the next version of the web. […] The post Who will pioneer the next web? appeared first on The Mozilla Blog.

The State of Mozilla: Are you ready to choose your future?

Tue, 27 Jan 2026 18:05:13 +0100

We’re at a fork in the road. AI is here, and has started to define how we search, create, communicate — and how the web itself works. Some of you love AI, but want it to work better for yourselves and society. Some of you hate it, and don’t want any of it. We get it. […] The post The State of Mozilla: Are you ready to choose your future? appeared first on The Mozilla Blog.

AI controls are coming to Firefox

Mon, 02 Feb 2026 18:00:32 +0100

AI is changing the web, and people want very different things from it. We’ve heard from many who want nothing to do with AI. We’ve also heard from others who want AI tools that are genuinely useful. Listening to our community, alongside our ongoing commitment to offer choice, led us to build AI controls. Starting […] The post AI controls are coming to Firefox appeared first on The Mozilla Blog.

How to turn off AI features in Firefox, or choose the ones you want

Tue, 24 Feb 2026 18:56:53 +0100

Other browsers force AI features on users. Firefox gives you a choice. In the latest desktop version of Firefox, you’ll find an AI controls section where you can turn off AI features entirely — or decide which ones stay on. Here’s how to set things up the way you want. But first, what AI features […] The post How to turn off AI features in Firefox, or choose the ones you want appeared first on The Mozilla Blog.

Heading to India AI Impact Summit, Mozilla leaders call for investment in open source AI as a path to sovereignty

Fri, 13 Feb 2026 14:00:00 +0100

Mozilla is headed to New Delhi, India for the India AI Impact Summit 2026 next week with a message: Open Source is the path to both economic and digital sovereignty. Participating in dozens of events across the weeklong global forum, Mozilla leaders will make the case that a different kind of AI future is possible, […] The post Heading to India AI Impact Summit, Mozilla leaders call for investment in open source AI as a path to sovereignty appeared first on The Mozilla Blog.

Ajit Varma on Firefox’s new AI controls: ‘We believe in user choice’

Thu, 05 Mar 2026 18:06:26 +0100

This is an edited transcript of an episode of Outside the Fox, Firefox’s flagship podcast, where we explore what’s happening online and why it matters. Stay up to date by subscribing on YouTube, Apple Podcasts, Spotify, or your favorite podcast app. On Outside the Fox, my co-host Kim Horcher and I spend a lot of […] The post Ajit Varma on Firefox’s new AI controls: ‘We believe in user choice’ appeared first on The Mozilla Blog.

Hardening Firefox with Anthropic’s Red Team

Fri, 06 Mar 2026 11:30:00 +0100

For more than two decades, Firefox has been one of the most scrutinized and security-hardened codebases on the web. Open source means our code is visible, reviewable, and continuously stress-tested by a global community. A few weeks ago, Anthropic’s Frontier Red Team approached us with results from a new AI-assisted vulnerability-detection method that surfaced more […] The post Hardening Firefox with Anthropic’s Red Team appeared first on The Mozilla Blog.

The web should remain anonymous by default

Thu, 12 Mar 2026 13:00:00 +0100

The unique architecture of the web enables a much higher degree of user privacy than exists on other platforms. Many factors contribute to this, but an essential one is that you don’t need to log in to start browsing. Sharing details about yourself with a website is an optional step you can take when you […] The post The web should remain anonymous by default appeared first on The Mozilla Blog.

Under the hood: The AI powering Firefox’s Shake to Summarize

Thu, 12 Mar 2026 18:57:54 +0100

We recently released a feature in the Firefox iOS mobile app called “Shake to Summarize”. The reception was remarkably positive, earning an honorable mention on Time Magazine’s best inventions of 2025. For anyone unfamiliar with Shake to Summarize, it’s just what the name implies: when you’re browsing a webpage, you can shake your phone to […] The post Under the hood: The AI powering Firefox’s Shake to Summarize appeared first on The Mozilla Blog.

More reasons to love Firefox: What’s new now, and what’s coming soon

Tue, 17 Mar 2026 17:06:00 +0100

Firefox is for people who make their own choices online, from what stays private to the tools that help get things done. That commitment to choice shows up throughout the Firefox experience, and AI controls is just the latest example — making it possible to turn generative AI features off, on, or customize them feature […] The post More reasons to love Firefox: What’s new now, and what’s coming soon appeared first on The Mozilla Blog.

Meet Kit, your companion for a new internet era

Tue, 17 Mar 2026 16:00:00 +0100

The web shouldn’t feel like it’s working against you. Yet so much of it now is designed to pull you off course: endless feeds, pop-up windows and content that looks credible until it isn’t. Staying focused and trusting your next click takes more effort than it should. Firefox is here to help you navigate the […] The post Meet Kit, your companion for a new internet era appeared first on The Mozilla Blog.

Try Tab Notes in Firefox to leave a note on any page

Mon, 23 Mar 2026 20:00:00 +0100

Don’t remember why you have all those webpages open? Now you can leave yourself a note for any tab. Tab Notes — our latest experimental feature in Firefox — are designed to help you remember, reflect, and pick up where you left off on the web by letting you attach a short note to a […] The post Try Tab Notes in Firefox to leave a note on any page appeared first on The Mozilla Blog.

Split View in Firefox: Two tabs side by side, right where you need them

Mon, 23 Mar 2026 20:00:00 +0100

Much of what we do on the web involves looking at more than one thing at a time – booking tickets while checking your calendar, taking notes as you go through a report, or comparing options before making a purchase. The web is inherently multidimensional. For years, browsing this way meant bouncing back and forth […] The post Split View in Firefox: Two tabs side by side, right where you need them appeared first on The Mozilla Blog.

A free VPN you can trust, now built into Firefox

Tue, 24 Mar 2026 17:00:00 +0100

Today we’re introducing a free built-in VPN in Firefox, a new IP-protection feature designed to keep you even more private while you browse. We’re starting by offering an industry-leading 50 gigabytes of free VPN-browsing each month. Firefox has long focused on building privacy tools directly into the browser to protect you online. Over the years, […] The post A free VPN you can trust, now built into Firefox appeared first on The Mozilla Blog.

A free VPN you can trust, now built into Firefox

Tue, 24 Mar 2026 17:00:00 +0100

The Servo Blog: February in Servo: faster layout, pause and resume scripts, and more!

Tue, 31 Mar 2026 02:00:00 +0200

Servo 0.0.6 includes some exciting new features: and (@lukewarlow, #41237) ‘:modal’ selectors on (@lukewarlow, #42201) ‘@property’ rules (@yezhizhen, @Loirooriol, #42136, #42858) ‘alignment-baseline’ and ‘baseline-shift’ (@Loirooriol, #42361) ‘Content-Security-Policy: base-uri’ (@WaterWhisperer, #42272) partial support for (@TimvdLippe, #41959) partial support for ‘transform-style: preserve-3d’ (@simonwuelker, #42755) Plus a bunch of new DOM APIs: most of the Pointer Events API (@webbeef, #41290) the UserActivation API (@stevennovaryo, #42060) import.meta.resolve() (@Gae24, #42506) integrity in (@Gae24, #42604) the formData() method on Request (@Taym95, #42041) the alpha property on HTMLInputElement (@simonwuelker, #42293) tabIndex on HTMLElement and SVGElement (@mrobinson, @Loirooriol, #42913) fullscreenElement on Document and ShadowRoot (@onsah, #42401) toJSON() on PerformancePaintTiming (@shubhamg13, #42396) navigator.pdfViewerEnabled (@simonwuelker, #42277) keyPath on IDBIndex (@arihant2math, #42431) createIndex(), deleteIndex(), and index() on IDBObjectStore (@arihant2math, @bulltickr, #38840, #42440, #42443) This is a big update, so here’s an outline: Work in progress– accessibility, execCommand() Developer tools– localhost only by default, Inspector, Console, Debugger servoshell– servo:config, F5 to reload Embedding API– offline builds, user stylesheets, context menus, gamepad API More on the web platform– font fallback, cookies, IndexedDB, First and Largest Contentful Paint Performance and stability– about:memory, incremental layout, shared memory Bug fixes– Windows arm64, layout, DOM events, shadow DOM Donations– how you can help Servo flourish Work in progress We’ve started working on accessibility support for web content (@alice, @delan, #42333, #42402), gated by a pref (--pref accessibility_enabled). Each webview will be able to expose its own accessibility tree, which the embedder can then integrate into its own accessibility tree. As part of this work: AccessKit now supports combining accessibility trees with its new “subtree” feature (@DataTriny, @delan, @lukewarlow, @alice, AccessKit/accesskit#655, AccessKit/accesskit#641) egui has been migrated to the new AccessKit API (@delan, @lukewarlow, @lucasmerlin, @DataTriny, emilk/egui#7850) we added a Servo API for activating accessibility features (@delan, @alice, #42336), although this has since become a WebView API We’ve started implementing document.execCommand() (@TimvdLippe, #42621, #42626, #42750), gated by a pref (--pref dom_exec_command_enabled). This feature is also enabled in experimental mode, and together with contenteditable, it’s critical for rich text editing on the web. The work done in February includes: document.queryCommandEnabled() (@TimvdLippe, #42634) document.queryCommandSupported() (@TimvdLippe, #42731) document.queryCommandIndeterm(), queryCommandState(), and queryCommandValue() (@TimvdLippe, #42748) the canonicalize whitespace algorithm – this is used by the ‘delete’, ‘forwardDelete’, and ‘insertText’ commands (@TimvdLippe, #42704) contentEditable on HTMLElement – for execCommand() only, excluding any support for interactive editing (@TimvdLippe, #42633, #42734) Developer tools DevTools has seen some big improvements in February! When enabled in servoshell, the DevTools server is more secure by default, listening only on localhost when only a port number is specified (@Narfinger, #42502). You can open the port for remote debugging by passing a full SocketAddr, such as --devtools=[::]:6080 or --devtools=0.0.0.0:6080. In the Inspector tab, you can now edit DOM attributes, and the DOM tree updates when attributes change (@simonwuelker, #42601, #42785). You can now list the event type and phase of event listeners attached to a DOM node as well (@simonwuelker, #42355). In the Console tab, objects can now be previewed when passed to console.log() and friends (@simonwuelker, #42296, #42510, #42752), and boolean values are now syntax highlighted (@pralkarz, #42513). In the Debugger tab, you can now pause and resume script execution, both manually and when breakpoints are hit (@eerii, @atbrakhi, #42599, #42580, #42874). We’ve also started working on other debugger features (@atbrakhi, @eerii, #42306), including stepping execution (@eerii, @atbrakhi, #42844, #42878, #42906), so once again stay tuned! Servo 0.0.6 showing DevTools debugger setting breakpoints, pausing on those breakpoints, and resuming script execution servoshell Back in August, we added a servo:preferences page to servoshell that allows you to set some of Servo’s most common preferences at runtime (@jdm, #38159). servoshell now has a servo:config page (@arihant2math, #40324), allowing you to set any preference, even internal ones. Note that preference changes are not yet persistent, and not all prefs take effect when changed at runtime. You can now press F5 to reload the page in servoshell (@Narfinger, #42538), in addition to pressing Ctrl+R or ⌘R. We’ve fixed a regression where the caret stopped being visible in the location bar (@mrobinson, #42470). Embedding API Servo is now easier to build offline, using the complete source tarball included in each release (@jschwe, #42852). Go to a release on GitHub, then download servo-[version]-src-vendored.tar.gz to get started. You can now add and remove user stylesheets with UserContentManager::add_stylesheet and remove_stylesheet, and remove user scripts with UserContentManager::remove_script (@mukilan, #42288). Previously user stylesheets were only configurable via servoshell’s --user-stylesheet option. User stylesheets work a bit differently to userstyles, since they cascade via the user origin, not the author origin. For more details about the tradeoffs, check out Customising the web: browsers as user agents (slides). Before opening any context menus on behalf of web content, Servo now closes any context menus that were opened by web content (@mrobinson, #42487), to avoid UI problems on some platforms. This is done by calling WebViewDelegate::hide_embedder_control before calling show_embedder_control in those cases. Input method events from web content now indicate whether or not the virtual keyboard should be shown (@stevennovaryo, @mrobinson, #42467), with the new InputMethodControl::allow_virtual_keyboard method. Generally the virtual keyboard should only be shown when the page has sticky activation. We’re reworking our gamepad API, with WebViewDelegate::play_gamepad_haptic_effect and stop_gamepad_haptic_effect being replaced by a new API that (as of the end of February at least) is known as GamepadProvider (@atbrakhi, #41568). The old methods are no longer called (#43743), and may be removed at some point. We now have better diagnostic output when we fail to create an OpenGL context (@mrobinson, #42873), including when the OpenGL versions supported by the device are too old. Servo::constellation_sender was removed (@jdm, #42389), since it was never useful to embedders. We’ve also made some changes to Preferences: devtools_server_port is now devtools_server_listen_address, and can now take either a port number (as before) or a full SocketAddr (@Narfinger, #42502) dom_worklet_blockingsleep is now dom_worklet_blockingsleep_enabled (@mukilan, #42897) Removed many unused preferences (@mukilan, #42897) – js_asyncstack, js_discard_system_source, js_dump_stack_on_debuggee_would_run, js_ion_offthread_compilation_enabled, js_mem_gc_allocation_threshold_avoid_interrupt_factor, js_mem_gc_allocation_threshold_factor, js_mem_gc_allocation_threshold_mb, js_mem_gc_decommit_threshold_mb, js_mem_gc_dynamic_heap_growth_enabled, js_mem_gc_dynamic_mark_slice_enabled, js_shared_memory, js_throw_on_asmjs_validation_failure, js_throw_on_debuggee_would_run, js_werror_enabled, and network_mime_sniff More on the web platform If you navigate to a video file or audio file as a document, the player now has controls (@webbeef, #42488). Images now rotate according to their EXIF metadata by default (@rayguo17, #42567), like they would once we add support for ‘image-orientation: from-image’. We’re implementing system-font-aware font fallback (@mrobinson, #42466), with support for this on macOS landing this month (@mrobinson, #42776). This allows Servo to render text in scripts that are not covered by web fonts or any of the fonts on Servo’s built-in lists of fallback fonts, as long as they are covered by fonts installed on the system. Servo now supports the newer pointermove, pointerdown, pointerup, and pointercancel events (@webbeef, #41290). The older touchmove, touchstart, touchend, and touchcancel events continue to be supported. The default language in ‘Accept-Language’ and navigator.language is now taken from the $LANG environment variable if present (@webbeef, #41919), rather than always being set to en-US. now supports any CSS color value (@simonwuelker, #42275), including the more complex values like color-mix(). We’ve also landed the colorspace attribute (@simonwuelker, #42279), but only in the web-facing side of Servo for now, not the embedding API or in servoshell. ‘vertical-align’ is now a shorthand for ‘alignment-baseline’ and ‘baseline-shift’ (@Loirooriol, #42361), and scrollParent on HTMLElement is now a function per this recent spec update (@TimurBora, #42689). Cookies are now more conformant (@sebsebmc, #42418, #42427, #42435). ‘Expires’ and ‘Max-Age’ attributes are now handled correctly in ‘Set-Cookie’ headers, get() and getAll() on CookieStore now trim whitespace in cookie names and values, and the behaviour of set() on CookieStore has been improved. elements are now more conformant in how load events are fired on the element and its contentWindow (@TimvdLippe, #42254), although there are still some bugs. This has long behaved incorrectly in Servo, and it has historically caused many problems in the Web Platform Tests. IndexedDB is now more conformant in our handling of transactions (@Taym95, #41508, #42732), and when opening and closing connections (@gterzian, @Taym95, #42082, #42669). We’ve started implementing Largest Contentful Paint timings (@shubhamg13, #42024), and we’ve landed a bunch of improvements to how First Contentful Paint timings work in Servo: we now include ‘background-image’ (@shubhamg13, #42569) we now include ‘border-image’ (@shubhamg13, #42581) we now ignore subtrees with ‘opacity: 0’ (@shubhamg13, #42768) we now ignore zero-sized subtrees (@shubhamg13, #42178) we now ignore (@shubhamg13, #42498) we now ignore and unless they actually have an image (@shubhamg13, #42411) we now ignore mouse moves when deciding when to stop measuring (@shubhamg13, #41999) new WebSocket() now resolves relative URLs (@webbeef, #42425). requestFullscreen() on Element now requires user activation (@stevennovaryo, #42060). performance.getEntries() now returns PerformanceResourceTiming entries for navigations in (@muse254, #42270). When geolocation is enabled (--pref dom_geolocation_enabled), navigator.geolocation.getCurrentPosition() and watchPosition() now support the optional errors argument (@arihant2math, #42295). We now support the ‘-webkit-text-security’ property in CSS (@mrobinson, #42181), which is not specified anywhere but required for MotionMark. Performance and stability Our about:memory page now knows how to report many new kinds of memory usage, including the DevTools server (@Narfinger, #42478, #42480), WebGL (@sagudev, #42570), localStorage and sessionStorage (@arihant2math, #42484), and some of the memory used by IndexedDB (@arihant2math, #42486). We’ve also started internally tracking the memory usage of the media subsystem (@Narfinger, #42504) and WebXR (@Narfinger, #42505). Layout has seen a lot of performance work in February, with our main focus being on improving incremental layout of the box tree and fragment tree. We now have our first truly incremental box tree layout (@mrobinson, @Loirooriol, @lukewarlow, #42700), rather than our previous “dirty roots”-based approach. Depending on how they were damaged, some boxes for floats (as above, #42816), independent formatting contexts (as above, #42783), and their descendants (as above, #42582) can now be reused, and they avoid damaging their parents (as above, #42847). We also destroy boxes with ‘display: none’ earlier in the layout process (as above, #42584). Incremental fragment tree layout is improving too! Whereas we previously had to decide whether to run fragment tree layout in an “all or nothing” way, we can now reuse cached fragments in independent formatting contexts (@mrobinson, @Loirooriol, @lukewarlow, #42687, #42717, #42871). We can also measure how much work is being done on each layout (as above, #42817). Servo uses shared memory for many situations where copying data over channels would be too expensive, such as for images and fonts. In multiprocess mode (--multiprocess), we use the operating system to create the shared memory in a way that can be shared with other processes, such as shm_open(3) or CreateFileMappingW, but this consumes resources that can sometimes be exhausted. We only need to use those kinds of shared memory in multiprocess mode, so we’ve reworked Servo to use Arc in single-process mode (@Narfinger, #42083), which should avoid resource exhaustion. Parsing web pages is complicated: we want pages to render incrementally as they stream in from the network, and we want to prefetch resources, but scripts can call document.write(), which injects markup “on the spot”. This is further complicated if that markup also contains a . We’ve recently landed some fixes to Servo’s async parser (@simonwuelker, #42882, #42910), which handles these issues more efficiently. This is currently an obscure and somewhat buggy feature (--pref dom_servoparser_async_html_tokenizer_enabled), but if we can get the feature working more reliably (#37418), it could halve the energy Servo spends on parsing, lower latency for pages that don’t use document.write(), and even improve the html5ever API for the ecosystem. We’ve also landed optimisations for ‘Content-Security-Policy’ (@Narfinger, #42716), IntersectionObserver (@Narfinger, @mrobinson, @stevennovaryo, #42366, #42390), layout queries (@webbeef, #42327), the bfcache (@Narfinger, #42703), loading images (@Narfinger, #42684), and checks for multiprocess mode (@Narfinger, #42782), as well as the interfaces between Servo and SpiderMonkey (@sagudev, #42135, #42576). We’ve continued our long-running effort to use the Rust type system to make certain kinds of dynamic borrow failures impossible (@Gae24, @pralkarz, @BryanSmith00, @sagudev, @Narfinger, @TimvdLippe, @kkoyung, @TimurBora, @onsah, #42342, #42294, #42370, #42417, #42619, #42616, #42637, #42640, #42662, #42679, #42681, #42665, #42667, #42699, #42712, #42725, #42729, #42726, #42720, #42738, #42737, #42735, #42751, #42805, #42809, #42780, #42820, #42715, #42635, #42880, #42846). Bug fixes We’ve landed some fixes for issues preventing Servo from being built on Windows arm64 (@dpaoliello, @npiesco, #42371, #42341). Work to enable Windows arm64 as a build platform is ongoing (@npiesco, #42312). now takes the default from the aspect ratio of the image (@Loirooriol, #42577), rather than using a width of 300px by default. and now take the default width and height (respectively) from the aspect ratio of the (@Loirooriol, #42545). We’ve fixed a bug in the result of layout queries, such as getBoundingClientRect(), on inline (@jdm, @Loirooriol, #42594), and we’ve fixed layout bugs related to ‘display: table-cell’ (@Loirooriol, #42778), ‘display: list-item’ (@Loirooriol, #42825, #42864), ‘inset: auto’ (@Loirooriol, #42586), ‘width: max-content’ (@mrobinson, @Loirooriol, @lukewarlow, #42574), ‘align-self: last baseline’ (@rayguo17, #42724), ‘list-style-image’ (@lukewarlow, #42332), ‘content: ’ (@lukewarlow, #42332), negative ‘margin’ (@Loirooriol, #42889), and ink overflow (@mrobinson, #42403). HTML and CSS bugs: Empty ‘url()’ values making requests when they shouldn’t (@rayguo17, #42622) failing to throw HierarchyRequestError when a DOM API is used to create an invalid hierarchy (@TimvdLippe, #42276) and selection behaviour being incorrect when the text contains more than one script (@mrobinson, #42399) validation failing to work correctly in some cases (@dyegoaurelio, #40956) failing to work correctly after the related is removed and a new one added with the same name (@jdm, #42344) not taking effect in some cases, or taking effect when given a data: or javascript: URL (@TimvdLippe, #42255, #42339) JavaScript and DOM bugs: event.target being incorrect on touchmove, touchend, and touchcancel events (@yezhizhen, #42654) touchmove events not being fired when part of a two-finger pinch zoom (@yezhizhen, #42528) touchend events erroneously firing after touchcancel events (@yezhizhen, #42654) assignedNodes() on HTMLSlotElement returning incorrect results after the was removed from the shadow tree (@rayguo17, #42250) Largest Contentful Paint timings no longer being collected after reloading or navigating (@shubhamg13, #41169) PerformancePaintTiming being exposed to Worker globals when they shouldn’t be (@shubhamg13, #42409) JavaScript modules resolved incorrectly when there are overlapping .imports or .scopes or import maps (@Gae24, #42668, #42630, #42754, #42821) changes to how we trigger garbage collection breaking Speedometer (@sagudev, #42271) WebDriver bugs: Pointer actions and wheel actions behaving incorrectly when devicePixelRatio ≠ 1 (@yezhizhen, #42387, #42628) Wheel actions throwing incorrect exceptions when they are missing properties (@yezhizhen, #42745) pointerMove actions with non-zero duration failing to interleave with other actions (@yezhizhen, #42289) We’ve fixed crashes in DevTools, in the Inspector tab (@eerii, @mrobinson, #42330), when exiting Servo while DevTools is connected (@simonwuelker, #42543), when setting breakpoints (@atbrakhi, #42810), and after clients disconnect (@simonwuelker, #42583). We’ve fixed crashes in layout, when using ‘background-repeat: round’ (@mrobinson, #42303), when using ‘list-style-image’ or ‘content: ’ (@lukewarlow, #42332), when calling elementFromPoint() on Document (@mrobinson, @Loirooriol, @lukewarlow, #42822), and when handling layout queries like getBoundingClientRect() on inline (@jdm, @Loirooriol, #42594). We’ve fixed crashes related to stylesheets, when removing stylesheets from the DOM (@TimvdLippe, #42273), when changing the href of a (@TimvdLippe, #42481), and when loading stylesheets with --layout-threads=1 (@mrobinson, @Loirooriol, @lukewarlow, #42685). We’ve also fixed crashes when using multitouch input (@yezhizhen, #42350), when using MediaStreamAudioSourceNode (@mrobinson, #42914), when calling add() on HTMLOptionsCollection (@mrobinson, #42263), when calling elementFromPoint() on Document or ShadowRoot(), when we fail to open a database for IndexedDB (@jdm, @mrobinson, #42444), and when certain pages are run with a mozjs debug build (@Gae24, #42428). Donations Thanks again for your generous support! We are now receiving 6985 USD/month (−0.4% from January) in recurring donations. This helps us cover the cost of our speedy CI and benchmarking servers, one of our latest Outreachy interns, and funding maintainer work that helps more people contribute to Servo. Servo is also on thanks.dev, and already 32 GitHub users (–1 from January) that depend on Servo are sponsoring us there. If you use Servo libraries like url, html5ever, selectors, or cssparser, signing up for thanks.dev could be a good way for you (or your employer) to give back to the community. We now have sponsorship tiers that allow you or your organisation to donate to the Servo project with public acknowlegement of your support. If you’re interested in this kind of sponsorship, please contact us at join@servo.org. 6985 USD/month 10000 Use of donations is decided transparently via the Technical Steering Committee’s public funding request process, and active proposals are tracked in servo/project#187. For more details, head to our Sponsorship page.

Mozilla and Mila announce strategic research partnership to advance open source and sovereign AI capabilities

Thu, 26 Mar 2026 17:58:13 +0100

The future of AI should belong to all of humanity, well beyond a handful of countries or companies. For that to happen, AI needs to be open, trusted, and built in ways that give people, institutions, and nations real choices. That’s why, today, Mozilla is announcing a strategic partnership with Mila – Quebec Artificial Intelligence Institute […] The post Mozilla and Mila announce strategic research partnership to advance open source and sovereign AI capabilities appeared first on The Mozilla Blog.

Firefox Tooling Announcements: MozPhab 2.10.0 Released

Tue, 31 Mar 2026 22:30:58 +0200

Bugs resolved in Moz-Phab 2.10.0: bug 2024404 Add --ai flag to moz-phab to trigger Review Helper automatically bug 2028164 moz-phab test failure: TypeError: Object of type AiReviewState is not JSON serializable Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix. 1 post - 1 participant Read full topic

Mozilla Localization (L10N): Localizer Spotlight: Cláudio

Wed, 01 Apr 2026 05:32:37 +0200

About you My name is Cláudio Esperança, I’m from Portugal. I speak Portuguese and English. I have been contributing to Mozilla localization projects for more than 18 years. Mozilla localization Q: How did you first get involved in localization, and what drew you to Mozilla? A: Curiosity has always driven me to understand how things work. Discovering open-source software, specifically Firefox and Linux, opened a world of limitless possibilities. I saw software translation not only as a way to improve my English but also as a great opportunity to start collaborating and contributing to the Mozilla mission. I began by following the community email list, contributing translations, and attending events. Before I knew it, I was leading the Portuguese translation team. Q: You contribute across many projects in Pontoon. Is there a product that stands out to you? Have you shared with family and friends what you have been doing and promoting the products? A: Firefox is always my favorite and the browser I use most regularly, as I trust it with my personal data. However, I contribute to all projects to provide users with more people-focused, secure, and private options, in a market often dominated by other vested interests. I don’t actively promote my work, as I prefer when people discover Mozilla products because they are the best solution for their needs. It may seem counterintuitive, but actually, I love when I see someone using Firefox, or another Mozilla product, not because they feel pressured by something I said, but because they’ve discovered it’s the best solution for them. It is very gratifying to know that the strings I translate are used by thousands of people every day, including family, friends, coworkers, and many other people which I probably will never know. Q: What have been some of the most rewarding or impactful projects you’ve localized? A: Firefox is undoubtedly the most impactful due to its fundamental role on the web. I also found Firefox OS particularly interesting: the concept was great, and it had great potential, but unfortunately it didn’t go as far as I would have liked. I still hope to see it reborn in some form one day. Q: What advice would you give to someone considering contributing to Mozilla localization today? A: One of the best things about L10n at Mozilla is how accessible localization has become. You don’t need to be a developer to make a difference. Whether by starting with a smaller project to build up confidence or diving straight into a high-impact application, or focus on a tool you love or explore something entirely new, the choice is yours. The most important step is simply to begin. And there’s no such thing as a ‘small’ contribution — every translated word helps to build a more inclusive internet for everyone. Community & leadership Cláudio and Kit, celebrating 18+ years of Mozilla localization. Q: How does the Portuguese localization community collaborate today? A: The Portuguese community is small, and we don’t have many members with recurring contributions. One of the reasons they give for this disengagement is that they feel their help isn’t needed because our translation completion rate is high (which isn’t true at all). There are other reasons like lack of time (main reason), and the fact that a large portion of the user base are pretty comfortable using software in English, Brazilian, or Spanish. Regarding community communication, while we previously used various discussion groups, we now primarily communicate via email and direct contact, with most of the work happening directly on Pontoon. Q: You’ve been leading the team for many years. How do you approach mentorship and conflict resolution? A: When I started, I didn’t have a mentor, so I had to rely on Mozilla’s resources and some reverse engineering. Today, platforms like Pontoon and SUMO make the process much easier for volunteers. Regarding conflicts, like all communities, we sometimes face significant challenges regarding personality and linguistic differences. Overall, we try to maintain a positive, constructive, and inclusive attitude, where all well-founded contributions are welcome. We use a democratic process for most decisions, with a “benevolent dictator” model as a final fallback if consensus cannot be reached. Professional background & skills Q: What is your professional background, and how has it influenced your localization work? A: I have a background in software engineering (Master’s in Mobile Computing, Bachelor’s in Information Systems, technical training in TCP/IP networks, Linux, and other technologies). This experience helps me handle technical aspects of software translation like placeholder syntax, HTML tags, and technical terminology, though modern tools like Pontoon have made localization much more accessible to everyone. Q: How has localization influenced your professional work? A: Localization provides a unique perspective on applications by allowing a deeper understanding of how they work. We get to learn about the various options available in the software, sometimes hidden in the more obscure areas of the application. Unlike more traditional applications that rely on older technologies, applications developed within the Mozilla ecosystem are at the forefront of web innovation, allowing early exposure to the future of the Internet. As a software engineer, I incorporate these insights into my own projects to create more modern and user-friendly solutions. Q: After 18+ years, what keeps you motivated to continue contributing? A: Our mission remains unfinished. We have a responsibility to ensure the internet remains a global public resource that doesn’t require English as a barrier to entry. In an era where AI and massive platforms are consolidating power, the need for diverse alternatives has never been more urgent. Localizing Mozilla products into my native language is my way of practicing digital activism. It’s incredibly rewarding to know that a handful of translated sentences can improve the lives of so many people instantly. The mission continues… Interesting facts Q: Tell us something unexpected about yourself. A: How someone born on an island in the Azores, who lived in half a dozen different cities in a country as small as Portugal, and who has worked as a farmer, shepherd, beekeeper, construction worker, electrician, trainer, programmer, and software engineer ended up translating world-class open-source software is a difficult story to explain. Ultimately, I think it all comes back to curiosity…

Firefox Tooling Announcements: MozPhab 2.11.1 Released

Thu, 02 Apr 2026 22:26:38 +0200

Bugs resolved in Moz-Phab 2.11.1: bug 2028700 Only request AI review for updates if the --ai flag is passed Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix. 1 post - 1 participant Read full topic

Firefox Tooling Announcements: MozPhab 2.11.0 Released

Wed, 01 Apr 2026 18:33:10 +0200

Bugs resolved in Moz-Phab 2.11.0: bug 2026935 moz-phab submit: add --test-plan flag Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix. 1 post - 1 participant Read full topic

The Rust Programming Language Blog: Changes to WebAssembly targets and handling undefined symbols

Sat, 04 Apr 2026 02:00:00 +0200

Rust's WebAssembly targets are soon going to experience a change which has a risk of breaking existing projects, and this post is intended to notify users of this upcoming change, explain what it is, and how to handle it. Specifically, all WebAssembly targets in Rust have been linked using the --allow-undefined flag to wasm-ld, and this flag is being removed. What is --allow-undefined? WebAssembly binaries in Rust today are all created by linking with wasm-ld. This serves a similar purpose to ld, lld, and mold, for example; it takes separately compiled crates/object files and creates one final binary. Since the first introduction of WebAssembly targets in Rust, the --allow-undefined flag has been passed to wasm-ld. This flag is documented as: --allow-undefined Allow undefined symbols in linked binary. This options is equivalent to --import-undefined and --unresolved-symbols=ignore-all The term "undefined" here specifically means with respect to symbol resolution in wasm-ld itself. Symbols used by wasm-ld correspond relatively closely to what native platforms use, for example all Rust functions have a symbol associated with them. Symbols can be referred to in Rust through extern "C" blocks, for example: unsafe extern "C" { fn mylibrary_init(); } fn init() { unsafe { mylibrary_init(); } } The symbol mylibrary_init is an undefined symbol. This is typically defined by a separate component of a program, such as an externally compiled C library, which will provide a definition for this symbol. By passing --allow-undefined to wasm-ld, however, it means that the above would generate a WebAssembly module like so: (module (import "env" "mylibrary_init" (func $mylibrary_init)) ;; ... ) This means that the undefined symbol was ignored and ended up as an imported symbol in the final WebAssembly module that is produced. The precise history here is somewhat lost to time, but the current understanding is that --allow-undefined was effectively required in the very early days of introducing wasm-ld to the Rust toolchain. This historical workaround stuck around till today and hasn't changed. What's wrong with --allow-undefined? By passing --allow-undefined on all WebAssembly targets, rustc is introducing diverging behavior between other platforms and WebAssembly. The main risk of --allow-undefined is that misconfiguration or mistakes in building can result in broken WebAssembly modules being produced, as opposed to compilation errors. This means that the proverbial can is kicked down the road and lengthens the distance from where the problem is discovered to where it was introduced. Some example problematic situations are: If mylibrary_init was typo'd as mylibraryinit then the final binary would import the mylibraryinit symbol instead of calling the linked mylibrary_init C symbol. If mylibrary was mistakenly not compiled and linked into a final application then the mylibrary_init symbol would end up imported rather than producing a linker error saying it's undefined. If external tooling is used to process a WebAssembly module, such as wasm-bindgen or wasm-tools component new, these tools don't know what to do with "env" imports by default and they are likely to provide an error message of some form that isn't clearly connected back to the original source code and where the symbols was imported from. For web users if you've ever seen an error along the lines of Uncaught TypeError: Failed to resolve module specifier "env". Relative references must start with either "/", "./", or "../". this can mean that "env" leaked into the final module unexpectedly and the true error is the undefined symbol error, not the lack of "env" items provided. All native platforms consider undefined symbols to be an error by default, and thus by passing --allow-undefined rustc is introducing surprising behavior on WebAssembly targets. The goal of the change is to remove this surprise and behave more like native platforms. What is going to break, and how to fix? In theory, not a whole lot is expected to break from this change. If the final WebAssembly binary imports unexpected symbols, then it's likely that the binary won't be runnable in the desired embedding, as the desired embedding probably doesn't provide the symbol as a definition. For example, if you compile an application for wasm32-wasip1 if the final binary imports mylibrary_init then it'll fail to run in most runtimes because it's considered an unresolved import. This means that most of the time this change won't break users, but it'll instead provide better diagnostics. The reason for this post, however, is that it's possible users could be intentionally relying on this behavior. For example your application might have: unsafe extern "C" { fn js_log(n: u32); } // ... And then perhaps some JS code that looks like: let instance = await WebAssembly.instantiate(module, { env: { js_log: n => console.log(n), } }); Effectively it's possible for users to explicitly rely on the behavior of --allow-undefined generating an import in the final WebAssembly binary. If users encounter this then the code can be fixed through a #[link] attribute which explicitly specifies the wasm_import_module name: #[link(wasm_import_module = "env")] unsafe extern "C" { fn js_log(n: u32); } // ... This will have the same behavior as before and will no longer be considered an undefined symbol to wasm-ld, and it'll work both before and after this change. Affected users can also compile with -Clink-arg=--allow-undefined as well to quickly restore the old behavior. When is this change being made? Removing --allow-undefined on wasm targets is being done in rust-lang/rust#149868. That change is slated to land in nightly soon, and will then get released with Rust 1.96 on 2026-05-28. If you see any issues as a result of this fallout please don't hesitate to file an issue on rust-lang/rust.

Mozilla Localization (L10N): Enhancing Comment Management in Pontoon

Fri, 03 Apr 2026 12:00:41 +0200

We’re excited to highlight the work of Serah Nderi, a volunteer contributor to Pontoon who has quickly made a meaningful impact on the project. Since getting involved earlier this year, Serah has contributed a steady stream of improvements — including 10 patches in just the past two months — ranging from good-first issues to fully fledged features. Serah joined the Mozilla community as an Outreachy intern on the SpiderMonkey team, where she demonstrated both strong technical skills and a passion for languages. That combination naturally led her to Pontoon, where she has been contributing not only as a developer but also as a localizer, exploring translations for languages like Kiswahili and Kikuyu. Her latest contribution introduces long-awaited functionality for editing and deleting comments in Pontoon, improving collaboration and moderation workflows for translators and project managers alike. You can follow Serah’s work on GitHub and connect with her on LinkedIn. Last year, I earned a B1 certification in German and TOPIK I certification in Korean. This year, I decided to explore something at the intersection of technology and languages, which led me to start contributing to Pontoon. Pontoon is Mozilla’s web-based localization platform, used by thousands of contributors to translate Firefox and other Mozilla projects into hundreds of languages. I began by adding Kiswahili translations and exploring localization for my mother tongue, Kikuyu. While Kikuyu doesn’t yet have a project manager and presents unique challenges, it made the experience even more interesting. After working on a few good-first issues, I decided to take on a larger challenge: implementing a full feature—the ability for users to edit and delete comments. Previously, users could only add comments. If a comment contained a typo or needed clarification, the only option was to add another comment. This often led to cluttered discussions and made collaboration less efficient. I set out to improve this experience. Under the hood The frontend implementation had a natural starting point. Pontoon comments already included actions like pinning, so adding Edit and Delete followed a similar interaction pattern. One of the main challenges was handling comment content. Comments in Pontoon are stored as serialized HTML paragraphs with support for @mentions. To enable editing, I needed to deserialize this stored content back into the editor so that users would see a fully functional input field pre-populated with their original comment—including mentions. When saving, the content is serialized again before being stored. In addition to the UI changes, I implemented the backend views for editing and deleting comments, along with the necessary tests. The final result allows users to edit and delete their own comments, while project managers can delete any comment for moderation purposes. This feature makes discussions in Pontoon more flexible, reduces noise from duplicate comments, and improves the overall collaboration experience for localization teams.

The Rust Programming Language Blog: docs.rs: building fewer targets by default

Sat, 04 Apr 2026 02:00:00 +0200

Building fewer targets by default On 2026-05-01, docs.rs will make a breaking change to its build behavior. Today, if a crate does not define a targets list in its docs.rs metadata, docs.rs builds documentation for a default list of five targets. Starting on 2026-05-01, docs.rs will instead build documentation for only the default target unless additional targets are requested explicitly. This is the next step in a change we first introduced in 2020, when docs.rs added support for opting into fewer build targets. Most crates do not compile different code for different targets, so building fewer targets by default is a better fit for most releases. It also reduces build times and saves resources on docs.rs. This change only affects: new releases rebuilds of old releases How is the default target chosen? If you do not set default-target, docs.rs uses the target of its build servers: x86_64-unknown-linux-gnu. You can override that by setting default-target in your docs.rs metadata: [package.metadata.docs.rs] default-target = "x86_64-apple-darwin" How do I build documentation for additional targets? If your crate needs documentation to be built for more than the default target, define the full list explicitly in your Cargo.toml: [package.metadata.docs.rs] targets = [ "x86_64-unknown-linux-gnu", "x86_64-apple-darwin", "x86_64-pc-windows-msvc", "i686-unknown-linux-gnu", "i686-pc-windows-msvc" ] When targets is set, docs.rs will build documentation for exactly those targets. docs.rs still supports any target available in the Rust toolchain. Only the default behavior is changing.

Firefox Tooling Announcements: Engineering Effectiveness Newsletter (Q1 2026 Edition)

Tue, 07 Apr 2026 17:37:38 +0200

Welcome to the Q1 edition of the Engineering Effectiveness Newsletter! The Engineering Effectiveness org makes it easy to develop, test and release Mozilla software at scale. See below for some highlights, then read on for more detailed info! Highlights Suhaib Integrated Review Helper with Phabricator and moz-phab making AI-powered code review quick and simple. Connor Sheehan implemented ETL from Lando to STMO, which allows us to get better visibility into lando’s performance and usage. Firefox 150 will ship with new PDF editing features completed by Calixte, letting users delete, copy, move, and export pages to a new PDF. Detailed Project Updates AI for Development Suhaib Mujahid integrated Review Helper with Phabricator, enabling AI-powered code review directly from patches by clicking a “Request AI Review” button, allowing it to analyze the patch and post comments with any findings. Suhaib Mujahid extended moz-phab to support requesting an AI review at patch submission time, enabling contributors to trigger Review Helper analysis directly from the command line via moz-phab --ai. Bugzilla Marco trained a new model in bugbug to detect bugs that are accessibility-related and missing the “access” keyword, to bring them to the attention of the accessibility team First bugs found: Bug 2026654, Bug 2026647, Bug 2025992 Two fixes from dkl to improve the reliability of the background bot that syncs Phabricator revisions with Bugzilla bugs. Kohei updated the markdown comment editor now intelligently handles pasting URLs. When you paste a URL while text is selected, it automatically formats it as a markdown link “selected text”. Kohei has also done significant improvements to the Guided Bug Entry page for new Bugzilla pages that should be going live soon. Build System and Mach Environment Better scheduling of rust dependencies through Bug 2011880 leads to ~1m saving in build time for opt build with hot cache. Warning flags can no longer be added directly to CFLAGS or CXXFLAGS in moz.build, they have to go in COMPILE_FLAGS[“WARNINGS_CXXFLAGS”] (resp. COMPILE_FLAGS[“WARNINGS_CFLAGS”]) (see Bug 1986258) Firefox-CI, Taskcluster and Treeherder Matt Boris upgraded FxCI to use RabbitMQ quorum queues and upgraded pulse to the latest available version for performance, security, and reliability. Abhishek Madan migrated schema validation from Voluptuous to msgspec across taskgraph, mozilla-taskgraph, and firefox, resulting in a 30% improvement to decision task times. Bug for conversion in Firefox, PR in Taskgraph, PR in Mozilla-Taskgraph Abhishek Madan moved Firefox from a vendored copy of taskgraph to PyPI installs at setup time, enabling support for packages that include compiled components. Patch stack Andrew Halberstadt made lots of progress migrating CI to Github, currently being used by mozilla/enterprise-firefox: Support for actions Fixed index and Treeherder routes Support for mach try Added pull_request_number as a parameter Andrew Halberstadt wrote a patch implementing the ability for the Taskcluster Github service to trigger hooks listed in .taskcluster.yml files. This will pave the way to share cross-project workflows and simplify in-repo configuration. Cameron Dawson upgraded major frontend libraries of Treeherder Lint, Static Analysis and Code Coverage New linter for header guards, through bug 2009182, triggered by mach lint --linter header-guards . It enforces our code style. A limited subset of clang-tidy’s static analysis is now run and enforced on our whole codebase. It is also reported during review on phabricator (see Bug 2023518 and related bugs) ESLint and Prettier have been updated to the latest versions. This included a fix for eslint-plugin-jsdoc check-property-names rule which was raising some false-positives in firefox-main. eslint-env comments are being removed as ESLint v9 does not support them (use eslint-file-globals.config.mjs instead). ESLint v10 (currently in rc) will raise errors for them. More eslint-plugin-jsdoc rules have been enabled across the whole tree. These are the ones relating to valid-jsdoc. A few remain, but will need work by teams to fix the failur The “Black” python formatter has now been replaced by “Ruff”. Marco greatly simplified the code coverage infrastructure, getting rid of two Heroku services, a frontend service, and a lot of code. The code coverage official UI is now Searchfox. Marco added a new mach command (“./mach coverage-report”) to generate a coverage report from a push. The command is documented on the code coverage page in the Firefox source docs. Teklia added added support for Github pull requests to Code Review Bot (prototype) PDF.js Calixte finished the implementation of the new reorganize and split functionality in PDF, which will ship in Firefox 150! Users will be able to delete, copy, move pages, and to export a subset of pages to a new PDF. Nicolò Ribaudo implemented the ability to open context menus on images in PDFs, allowing users to perform actions they are used to (such as downloading images). This was a long standing feature request (11 years!). Firefox Translations Evgeny Pavlov, Jaume Zaragoza-Bernabeu, and Sergio Ortiz Rojas contributed to training both new and improved Translations models for use in Firefox. Bosnian Croatian Norwegian Bokmål Serbian Thai Traditional Chinese Vietnamese Erik Nordin fixed an issue where text contained within stand-alone SVG images was not being translated (Bug 2003545). Erik Nordin reworked the Translations settings to be compatible with the upcoming about:settings redesign (Bug 2002127). Erik Nordin helped design a system to control the enablement of AI Features within Firefox, and worked to make the entire Translations feature set have the capability to be turned off and back on within the same browsing session (Bug 2010922, Bug 2010993). Erik Nordin reworked the about:translations page in order to get it ready for an official release with a URL-bar QuickAction entry point. (Bug 2004463, Bug 2016677, Bug 2015798, Bug 2016658, Bug 2016675, Bug 2016690, Bug 2019753, Bug 2020014, Bug 2020062, Bug2020067, Bug2022838, Bug 1814168, Bug 1814195, Bug 1841109, Bug 1869772, Bug 1879933, Bug 1970962, Bug 1990333, Bug 1991224, Bug 1992230, Bug 1992231, Bug 1992232, Bug 1992233, Bug 2000959, Bug 2004471, Bug 2004473, Bug 2019119, Bug 2019120, Bug 1970963, Bug 2004454, Bug 2010399, Bug 2023677, Bug 1836451, Bug 1999999, Bug 2004476, Bug 2004477, Bug 2004479, Bug 2004962, Bug 2007007, Bug 2007194, Bug 2007551, Bug 2008213, Bug 2008257, Bug 2010335, Bug 2019116, Bug 2019117, Bug 2019121, Bug 2019123, Bug 2020697, Bug 2020841, Bug 2024467) Thank you to Dasha Andriyenko for designing the visuals and UX of the page. Thank you to Kim Bryant for managing the product and release considerations. Thank you to Sam Foster and Greg Tatum who reviewed a significant portion of the code. Thank you to Ciprian Georgiu and Giorgia Nichita for testing quality assurance. Thank you to Anna Yeddi for reviewing engineering accessibility characteristics. Thank you to Dale Harvey for designing the QuickAction system that this feature plugs into. Leonardo Paffi improved our testing capabilities by allowing us to serve inline HTML on the fly, rather than having to add an HTML file into the repository. This eases the burden of overhead to test special-case language characteristics, and ultimately helped us release Norwegian Bokmål (Bug 1996967). Leonardo Paffi improved our handling of the macro language tag for Norwegian (no) to be compatible with our support for Norwegian Bokmål translations (Bug 2019123). Tyler Etchart removed in-code references to quality estimation models, which are not utilized during translation inference within Firefox (Bug 1889753). Tyler Etchart updated the generated Translations WASM JavaScript code to have explicit. comments expressing that the file is generated and should not be modified (Bug 1968038). Tyler Etchart removed some old dead code related to prior ideas for Translations within Firefox (Bug 1996681). Emilio Cobos Álvarez fixed an issue where the checkboxes within the Full-Page Translations Panel settings menu were no longer appearing (Bug 2010234). Phabricator, moz-phab, and Lando Connor Sheehan implemented ETL from Lando to STMO, which allows us to get better visibility into lando’s performance and usage, e.g., the new uplift feature: Client Challenge Zeid continues spear-heading the GitHub PR pilot, gathering feedback and fixing usability issues as they are reported. One key focus was on supporting triggering the Code Review Bot on request, via pushes to try. Olivier Mehani added backward-compatible support for try pushes in the new instance of lando. It will become the default soon, but you can try it out now by setting LANDO_TRY_CONFIG=lando-prod-new in your environment prior to running `mach try . Olivier Mehani landed a small change to lando, to make the current Tree Status visible on main landing pages (Bug 2025629). This, with the landing queue visible on the job details pages, should help get a better understanding of why jobs sometimes seem to take longer than expected to land. moz-phab had several new releases: Suhaib Mujahid added the --ai flag and submit.ai_review commit option to request an AI review of patches at submission time. Johan Lorenzo added the --test-plan flag to enable submitting a test plan from the CLI, which is useful for working with AI agents See the release notes here: MozPhab 2.8.2 Released MozPhab 2.8.3 Released MozPhab 2.9.0 Released MozPhab 2.9.1 Released MozPhab 2.10.0 Released MozPhab 2.11.0 Released https://discourse.mozilla.org/t/mozphab-2-11-1-released/147821/1 Release Engineering and Release Management Ben Hearsum added new tests to verify update integrity on mozilla-central. Julien Cristau updated the docker images for many build and related tasks from Debian 12 to Debian 13 Relman streamlined the release process by removing the Nightly soft code freeze and adjusting the Beta schedule to reduce end-of-cycle friction, create more effective stabilization time, and simplify release candidate workflows. We now ship to the Xiaomi Store. Delivered mid-cycle ESR dot releases to address critical security fixes ahead of the standard cadence, improving responsiveness while coordinating across multiple ESR versions and release channels. Andrew Halberstadt helped support and build out the Firefox Enterprise release pipeline. Release Operations Mark Cornmesser improved Windows hardware management, including self-configuration and self-deployment capabilities, automated BIOS management, and standardization of BIOS settings across performance testing environments to ensure consistency and reliability. Other Thanks to Bug #2013401 mozilla::Maybe generates better and denser code, which led to a reduction of 300kB for libxul.so Thanks to A new clang-tidy pass we’ve been able to automatically add std::move in location where it could improve performance (see Bug 2012658) Thanks for reading and see you next quarter! 1 post - 1 participant Read full topic

Firefox Tooling Announcements: MozPhab 2.12.0 Released

Wed, 08 Apr 2026 20:04:04 +0200

Bugs resolved in Moz-Phab 2.12.0: bug 2029015 Clean up previous_commit state tracking bug 2029072 Using moz-phab uplift --assessment-id shouldn’t require extra browser clicks Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix. 1 post - 1 participant Read full topic

Firefox Tooling Announcements: New Deploy of PerCompare April 7th

Wed, 08 Apr 2026 00:05:18 +0200

The latest version of PerfCompare is now live! Check out the change-log below to see the updates: [kala] Bug: 2020622 Updated column title from Total Runs to Total Trials #1012 Bug 2024075 Test Version Refactor: Moved subtest columns to test version strategy and test version files #1017 Bug 2022720 Test Version Refactor: Refactor how the expanded row’s components are rendered #1016 Bug 2027906 Test Version Refactor: remove hard coded array in Test Version Dropdown and replace with call to label options in registry #1020 Bug 2026342 : Replace truncated subtest names with full name #1023 [moijes12] Bug-2020964 Update Contributing section in README #1009 Bug-2022758 Remove redundant Dark fonts #1011 [padenot] Median diff gated #1019 [mgaudet] Bug 2024042 - Add median diff column #1015 Thank you for the contributions! Bugs or feature request can be filed on Bugzilla. The team can also be found on the #perfcompare channel on Element. Come and chat! 1 post - 1 participant Read full topic

Andreas Farre: BuildCache now works with mach

Thu, 09 Apr 2026 02:00:00 +0200

I’m happy to announce that buildcache is now a first-class compiler cache in mach. This has been a long time coming, and I’m excited to finally see it land. For those unfamiliar, buildcache is a compiler cache that can drastically cut down your rebuild times by caching compilation results. It’s similar to ccache, but even more so sccache, in that it supports C/C++ out of the box, as well as Rust. It has some nice unique properties of its own though, which we’ll look at more closely in following posts. Getting started Setting it up is straightforward. Just add the following to your mozconfig: ac_add_options --with-ccache=buildcache Then build as usual: ./mach build That’s it. Give it a try If you run into any issues, please file a bug and tag me. I’d love to hear how it works out for people, and any rough edges you might hit.

0DIN is open-sourcing AI security and the hard-earned knowledge behind it

Thu, 09 Apr 2026 18:35:02 +0200

We’re launching across the developer and security community this week on Product Hunt and Hacker News. If you’ve been following AI security, we’d love your support and your feedback. At Mozilla, open source has never been just a licensing choice. It’s a conviction: the internet gets healthier when tools and knowledge circulate freely, when anyone […] The post 0DIN is open-sourcing AI security and the hard-earned knowledge behind it appeared first on The Mozilla Blog.

The Mozilla Blog: Old habits die hard: Microsoft tries to limit our options, this time with AI

Thu, 09 Apr 2026 19:03:46 +0200

Microsoft recently announced it’s pulling back Copilot from several of its core Windows apps — Photos, Notepad, the Snipping Tool, and Widgets. Rolling back these forced AI integrations is the right move, but this is just the most recent example of Microsoft going too far without user consent. Copilot was pushed onto users Over the past year, Copilot wasn’t offered to Windows users — it was installed on them. The M365 Copilot app began auto-installing on any Windows device running Microsoft 365 desktop apps, with no prompt and no consent. A new physical keyboard key was added to laptops that launched Copilot by default, with no simple way to remap it. By default, Copilot was pinned to the taskbar starting with Windows 11 PCs. And, going a step further, Microsoft planned to embed it into three of the most fundamental surfaces for the operating system: the Windows notification center, the Settings app, and File Explorer. Then came the user backlash. When Microsoft says it now wants to be “intentional” about Copilot, they’re really admitting that they made repeated choices to serve their business over their customers. This isn’t the first time – Microsoft has a pattern of deceptive design patterns The pattern of behavior here isn’t new. Independent research commissioned by Mozilla has documented how Microsoft uses design and distribution tactics to override user choice — from deliberately complicated processes for changing your default browser, to UI that routes users back to Microsoft’s Edge browser even after they’ve explicitly chosen something else. Since Mozilla published that research, Microsoft has continued to escalate its use of dark patterns to force behaviors that help the bottom line, not people’s lives. Here are a few examples from the rollout of Windows 11 that have continued to strip users of their choice: The Windows Search bar, embedded in the taskbar on both Windows 10 and Windows 11, is hardcoded to only open Microsoft Edge, regardless of your default browser. Windows has not implemented a true device migration system, like we see with Android, iOS, and MacOS, where your apps, settings and data are all reflected on your new device when you buy a new computer. Instead, the defaults are changed back to Microsoft’s own products. Microsoft Outlook and Microsoft Teams by default ignore your default browser selection and open links directly in Edge. Windows does not offer a simple prompt that other browsers can trigger asking to become your default browser. Instead, other browsers have to direct you to Windows settings and hope you finish the multi-step process. The Copilot rollout followed the same playbook we’ve come to expect from Microsoft: use automatic installs, physical hardware, and default settings to force behaviors. In the most recent instance, they allowed their AI to learn and gather data as quickly as possible before people had a choice. What ‘genuinely useful’ AI integration actually looks like We, like Microsoft and basically every tech company, have been asking ourselves the same question: What does it mean for AI to be genuinely useful? For us, the answer is simple. AI should work on your terms, not ours. Firefox’s goal is to create AI enhancements that are made for people, not just because they can increase profit. We’ve rolled out AI-enhanced features that make browsing smarter, faster, and more personalized, such as translations that stay local on your device to help you browse the web in your preferred language, alt text in PDFs to add accessibility descriptions to images in PDF pages and tab grouping which suggests related tabs and group names. But we also know users deserve a choice. We built our answer into Firefox 148, introducing a centralized AI Controls panel in your browser settings including a single “Block AI Enhancements” switch that turns off every AI feature at once. Each option is also individually controllable. The premise is simple: You should decide whether AI is part of your browsing experience at all. Not Big Tech. Not Mozilla. You. And critically, your preferences also persist across browser updates, which means AI tools won’t silently re-enable themselves after a major upgrade. No reinstalling. No opting out again after the fact. It’s designed for people who care about what’s happening on their computer but shouldn’t have to become a systems administrator to stay in control of it. The stakes are bigger than one rollback When a company with Microsoft’s reach continues to control users — and only walks it back when the noise gets loud enough — it shapes what people expect from technology. It tells people that their only real move is to complain until, hopefully, the company relents. It also makes it harder for alternatives to compete when a company uses its reach and control to steer people back into its own products. We don’t think that’s the internet we have to accept. People have been clear about what they want when it comes to this era of the internet. They want to feel like they’re in control of their own devices and their own data. That’s the internet we’re trying to build. The post Old habits die hard: Microsoft tries to limit our options, this time with AI appeared first on The Mozilla Blog.

The Servo Blog: Servo is now available on crates.io

Mon, 13 Apr 2026 02:00:00 +0200

Today the Servo team has released v0.1.0 of the servo crate. This is our first crates.io release of the servo crate that allows Servo to be used as a library. We currently do not have any plans of publishing our demo browser servoshell to crates.io. In the 5 releases since our initial GitHub release in October 2025, our release process has matured, with the main “bottleneck” now being the human-written monthly blog post. Since we’re quite excited about this release, we decided to not wait for the monthly blog post to be finished, but promise to deliver the monthly update in the coming weeks. As you can see from the version number, this release is not a 1.0 release. In fact, we still haven’t finished discussing what 1.0 means for Servo. Nevertheless, the increased version number reflects our growing confidence in Servo’s embedding API and its ability to meet some users’ needs. In the meantime we also decided to offer a long-term support (LTS) version of Servo, since breaking changes in the regular monthly releases are expected and some embedders might prefer doing major upgrades on a scheduled half-yearly basis while still receiving security updates and (hopefully!) some migration guides. For more details on the LTS release, see the respective section in the Servo book.

Andreas Farre: How to make Firefox builds1 17% faster2

Fri, 10 Apr 2026 02:00:00 +0200

In the previous post, I mentioned that buildcache has some unique properties compared to ccache and sccache. One of them is its Lua plugin system, which lets you write custom wrappers for programs that aren’t compilers in the traditional sense. With Bug 2027655 now merged, we can use this to cache Firefox’s WebIDL binding code generation. What’s the WebIDL step? When you build Firefox, one of the earlier steps runs python3 -m mozbuild.action.webidl to generate C++ binding code from hundreds of .webidl files. It produces thousands of output files: headers, cpp files, forward declarations, event implementations, and so on. The step isn’t terribly slow on its own, but it runs on every clobber build, and the output is entirely deterministic given the same inputs. That makes it a perfect candidate for caching. The problem was that the compiler cache was never passed to this step. Buildcache was only wrapping actual compiler invocations, not the Python codegen. The change The fix in Bug 2027655 is small. In dom/bindings/Makefile.in, we now conditionally pass $(CCACHE) as a command wrapper to the py_action call: WEBIDL_CCACHE= ifdef MOZ_USING_BUILDCACHE WEBIDL_CCACHE=$(CCACHE) endif webidl.stub: $(codegen_dependencies) $(call py_action,webidl $(relativesrcdir),$(srcdir),,$(WEBIDL_CCACHE)) @$(TOUCH) $@ The py_action macro in config/makefiles/functions.mk is what runs Python build actions. The ability to pass a command wrapper as a fourth argument was also introduced in this bug. When buildcache is configured as the compiler cache, this means the webidl action is invoked as buildcache python3 -m mozbuild.action.webidl ... instead of just python3 -m mozbuild.action.webidl .... That’s all buildcache needs to intercept it. Note the ifdef MOZ_USING_BUILDCACHE guard. This is specific to buildcache because ccache and sccache don’t have a mechanism for caching arbitrary commands. Buildcache does, through its Lua wrappers. The Lua wrapper Buildcache’s Lua plugin system lets you write a script that tells it how to handle a program it doesn’t natively understand. The wrapper for WebIDL codegen, webidl.lua, needs to answer a few questions for buildcache: Can I handle this command? Match on mozbuild.action.webidl in the argument list. What are the inputs? All the .webidl source files, plus the Python codegen scripts. These come from file-lists.json (which mach generates) and codegen.json (which tracks the Python dependencies from the previous run). What are the outputs? All the generated binding headers, cpp files, event files, and the codegen state files. Again derived from file-lists.json. With that information, buildcache can hash the inputs, check the cache, and either replay the cached outputs or run the real command and store the results. The wrapper uses buildcache’s direct_mode capability, meaning it hashes input files directly rather than relying on preprocessed output. This is the right approach here since we’re not dealing with a C preprocessor but with a Python script that reads .webidl files. Numbers Here are build times for ./mach build on Linux, comparing compiler cachers. Each row shows a clobber build with an empty cache (cold), followed by a clobber build with a filled cache (warm): tool cold warm with plugin none 5m35s n/a n/a ccache 5m42s 3m21s n/a sccache 9m38s 2m49s n/a buildcache 5m43s 1m27s 1m12s The “with plugin” column is buildcache with the webidl.lua wrapper active. It shaves another 15 seconds1, bringing the total down to 1m12s2. Not a revolutionary improvement on its own, but it demonstrates the mechanism. The WebIDL step is just the first Python action to get this treatment; there are other codegen steps in the build that could benefit from the same approach. More broadly, these numbers show buildcache pulling well ahead on warm builds. Going from a 5m35s clean build to a 1m12s cached rebuild is a nice improvement to the edit-compile-test cycle. These are single runs on one machine, not rigorous benchmarks, but the direction is clear enough. Setting it up If you’re already using buildcache with mach, the Makefile change is available when updating to today’s central. To enable the Lua wrapper, clone the buildcache-wrappers repo and point buildcache at it via lua_paths in ~/.buildcache/config.json: { "lua_paths": ["/path/to/buildcache-wrappers/mozilla"], "max_cache_size": 10737418240, "max_local_entry_size": 2684354560 } Alternatively, you can set the BUILDCACHE_LUA_PATH environment variable. A convenient place to do that is in your mozconfig: mk_add_options "export BUILDCACHE_LUA_PATH=/path/to/buildcache-wrappers/mozilla/" The large max_local_entry_size (2.5 GB) is needed because some Rust crates produce very large cache entries. What’s next The Lua plugin system is the interesting part here. The WebIDL wrapper is a proof of concept, but the same technique applies to any deterministic build step that takes known inputs and produces known outputs. There are other codegen actions in the Firefox build that could get the same treatment, and I plan to explore those next. Notes For a clobber build with a warm cache ↩ On my machine ↩

Mozilla Privacy Blog: Anti-hacking laws should not be used to lock up the open internet

Mon, 13 Apr 2026 18:51:39 +0200

Mozilla has joined EFF, the Alliance for Responsible Data Collection, Digital Medusa, and EleutherAI in filing an amicus brief in Amazon v. Perplexity, urging the Ninth Circuit not to stretch the Computer Fraud and Abuse Act (CFAA) far beyond its intended purpose. We have said this before, and it remains true: laws designed to protect the security of the internet should not be used to undermine how people want to use it. Our mission is grounded in the idea that the internet must remain open and accessible to all, and that privacy and security online are fundamental. Mozilla joined this brief because overly broad interpretations of computer crime laws can put those values at risk. The CFAA is an anti-hacking law. It was meant to address break-ins to computer systems — not to criminalize tools that enable people to access and engage with information that is publicly available on the web. While there are no-doubt many challenging legal and policy questions around the growth and use of agentic AI tools, we believe expanding the reach of CFAA to address these issues would threaten innovation, chill the development of useful tools and services for researchers and journalists, and undermine competition online. The post Anti-hacking laws should not be used to lock up the open internet appeared first on Open Policy & Advocacy.

Spidermonkey Development Blog: Benchmark Mode in SpiderMonkey

Mon, 13 Apr 2026 19:00:00 +0200

You ever get to the end of running benchmarks, maybe a long running one, and realize… “Oh no. I forgot to set that important option, and these results are useless” Yeah. I have. Too many times. So I’ve added --benchmark-mode and --strict-benchmark-mode to SpiderMonkey. These options configure the shell for benchmarking, taking the wisdom of the team and boiling multiple shell options down to a single --benchmark-mode flag, and in --strict-benchmark-mode will abort the run if the shell is configured in a way where effective benchmarking is unlikely to be possible (e.g. benchmarking a debug build!) The nice thing about nailing this down is that this is something we can point anyone to and know that their shell is following the rules any of us would follow. The general design philosophy of benchmark mode is to disable things you wouldn’t see enabled in Firefox in normal configuration, as well as debugging code that maybe makes sense for test suites but doesn’t make sense for a benchmark. Hopefully this is the end of me realizing that I forgot to pass --no-async-stacks yet again.

Firefox Application Security Team: Firefox Security & Privacy Newsletter 2026 Q1

Wed, 15 Apr 2026 01:00:00 +0200

Welcome to the Q1 2026 edition of the Firefox Security & Privacy Newsletter. Security and privacy are foundational to Mozilla’s manifesto and central to how we build Firefox. In this edition, we highlight key security and privacy work from Q1 2026, organized into the following areas: Firefox Product Security & Privacy — new security and privacy features and integrations in Firefox Community Engagement — updates from our security research and bug bounty community Web Security & Standards — advancements that help websites better protect their users from online threats Preface Note: Some of the bugs linked below might not be accessible to the general public and restricted to specific work groups. We de-restrict fixed security bugs after a grace-period, until the majority of our user population have received Firefox updates. If a link does not work for you, please accept this as a precaution for the safety of all Firefox users. Firefox Product Security & Privacy Collaboration with Anthropic: A few weeks ago, Anthropic’s Frontier Red Team shared the results of a new AI-assisted vulnerability detection approach. Using this method, we have identified more than a dozen confirmed security issues, each supported by reproducible test cases. Learn more in our blog: Hardening Firefox with Anthropic’s Red Team. Leveraging our Firefox Security expertise, we ended up finding dozens of additional vulnerabilities that were fixed in the following Firefox updates. YouTube coverage of Firefox at pwn2own 2025: To demonstrate Firefox’s focus on user security and Mozilla’s commitment to openness, we invited LiveOverflow to follow us during the prestigious hacking competition pwn2own last year. LiveOverflow’s four-party documentary provides behind-the-scenes coverage of our quick response to fixing two Firefox 0-day security bugs. The videos go from preparation (part 1), to exploit analysis (part 2) and disclosure (part 3), all the way to the rapid release of a Firefox update (part 4) for the 2-day event coverage. Trustworthy JavaScript for the Open Web: Alongside partners from Meta, Proton AG, Cloudflare, and the Freedom of the Press Foundation, we presented our plans to improve the trustworthiness of JavaScript on the Web at Real World Crypto. SafeBrowsing: Firefox 147 shipped with SafeBrowsing v5 support, allowing to protect users against malicious URLs. And starting with v149, Firefox blocks and revokes websites permissions for sites on the SafeBrowsing lists (Bug 1986300), leveling-up the built-in protection from online threats. Stronger XSS Protection through the Sanitizer API: Starting with v148, Firefox was the first browser to add support for the Sanitizer API, helping prevent XSS attacks on the web. Learn more in our blog post, Goodbye innerHTML, Hello setHTML: Stronger XSS Protection in Firefox 148, or tune in to the ShopTalk Show podcast, where Freddy Braun discusses the details of the Sanitizer API. 2048-bit Minimum for RSA Certificates: Firefox now enforces a minimum 2048-bit RSA key size for certificates issued by Mozilla’s built-in root CAs. As publicly trusted CAs already meet this requirement, no significant impact to the broader web is expected. Community Engagement Bug Bounty Program Updates: As the threat landscape evolves, addressing the increasing volume of AI-assisted security bug reports, we’re evolving our security program alongside it. With continued advances in browser security architecture, our bug bounty program is refining its incentives to prioritize the highest-impact research and the most critical classes of vulnerabilities while focusing on novelty. Learn more in our blogpost: Bug Bounty Program Updates 2026. We have also just updated our Bug Bounty hall of fame, to list all people who helped us find and fix security vulnerabilities in Q1 of 2026. Web Security & Standards Storage-Access Headers: Firefox 147 is shipping an extension of the Storage Access API to improve both web compatibility and parity with Chrome. These Storage Access headers allow web pages to opt out of storage isolation upfront and without the need to first load a document. Going Forward As a Firefox user, you automatically benefit from the security and privacy improvements described above through Firefox’s regular automatic updates. If you’re not using Firefox yet, you can download it to enjoy a fast, secure browsing experience—while supporting Mozilla’s mission of a healthy, safe, and accessible web for everyone. We’d like to thank everyone who helps make Firefox and the open web more secure and privacy-respecting. See you next time with the Q2 2026 report. — The Firefox Security and Privacy Teams

Mozilla Data YouTube Channel: Responsible Data Collection is Good, Actually (Ubisoft Data Summit 2021)

Mon, 13 Apr 2026 19:07:08 +0200

Firefox Telemetry Engineer and Data Steward Chris H-C (:chutten) gives a talk at Ubisoft's Data Summit 2021 about how Responsible Data Collection as practised at Mozilla makes cataloguing easy, stops instrumentation mistakes before they ship, and allows you to build self-serve analysis tooling that gets everyone invested in data quality. Oh, and it's cheaper, too.

Firefox Tooling Announcements: MozPhab 2.13.0 Released

Wed, 15 Apr 2026 17:30:43 +0200

Bugs resolved in Moz-Phab 2.13.0: bug 1925717 stop calling edge.search in moz-phab patch by making use of the stackGraph revision field bug 2030443 Switch to uv for package management in moz-phab bug 2031283 Parallelize network requests in moz-phab patch Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix. 1 post - 1 participant Read full topic

This Week In Rust: This Week in Rust 647

Wed, 15 Apr 2026 06:00:00 +0200

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions. This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR. Want TWIR in your inbox? Subscribe here. Updates from Rust Community Official Infrastructure Team 2026 Q1 Recap and Q2 Plan Project/Tooling Updates pquantum.dev: Post-Quantum Cryptography in Rust haproxy-spoe-rs: A Rust SPOA Agent Library for HAProxy Fresh 0.2.23: Terminal IDE adds Windows-1251 encoding, customizable status bar, and faster file finder KAIO v0.2.0: Writing GPU Kernels in Rust at 92.5% of cuBLAS RustNet: A Real-Time Network Traffic Analysis TUI AimDB: The Next Era of Software Architecture Is Data-First tailscale-rs v0.2.0: our new Rust library preview Sinbo: a CLI snippet manager, store code snippets locally with fuzzy search, encryption, and shell completions flodl v0.4.0: heterogeneous multi-GPU DDP with faster training and better convergence than solo GPU Observations/Thoughts The acyclic e-graph: Cranelift's mid-end optimizer Rust should have stable tail calls Flat Error Codes Are Not Enough No one owes you supply-chain security Everything Should Be Typed: Scalar Types Are Not Enough Borrow-checking surprises A Roadmap for Building an Extended Standard Library for Rust Okay, what ACTUALLY uses Rust? [audio] Netstack.FM episode 34 — Tokio with Carl Lerche (Ep 5 Remastered) Rust Walkthroughs Untangling Tokio and Rayon in production: From 2s latency spikes to 94ms flat Understanding Traceroute Bringing Rust to the Pixel Baseband Fixing DNS tail latency with a 5-line config and a 50-line function Debloat your async Rust Learn Rust Ownership and Borrowing By Building Mini Grep Profiling Rust: A Flamegraph vs PGO, BOLT, and Native CPU Targeting Bulletproof Rust Web: An opinionated guide to production-grade Axum applications A minimal VMM in Rust with KVM claudectl: Building a TUI Dashboard for AI Coding Agents in Rust [video] Build with Naz : Eliminate busy waiting with Rust Condvar Crate of the Week This week's crate is Myth Engine, a high-performance, cross-platform rendering engine. Thanks to Pan Xinmiao for the self-suggestion! Please submit your suggestions and votes for next week! Calls for Testing An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization. If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing. No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs. Let us know if you would like your feature to be tracked as a part of this list. Call for Participation; projects and speakers CFP - Projects Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started! Some of these tasks may also have mentors available, visit the task page for more information. No Calls for participation were submitted this week. If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon! CFP - Events Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker. EuroRust | CFP open until 2026-04-27 | Barcelona, Spain | 2026-10-14 - 2026-10-17 If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon! Updates from the Rust Project 519 pull requests were merged in the last week Compiler add #![unstable_removed(..)] attribute to track removed features add suggestion to .to_owned() used on Cow when borrowing avoid stack overflow in FindExprBySpan enable #[diagnostic::on_const] for local impls introduce a #[diagnostic::on_unknown] attribute reduce size of ImportData ty::Alias refactor semantic checks of impl restrictions stabilize s390x vector registers store chunk_domain_size explicitly in Chunk Library add const Default impls for LazyCell and LazyLock constify some Iterator methods constify DoubleEndedIterator constify Step for NonZero don't leak internal temporaries from dbg! explicitly forget the zero remaining elements in vec::IntoIter::fold() impl const Residual for ControlFlow initial functions to start on transmute v2 introduce #[diagnostic::on_move] on Rc make Box/Rc/Arc::into_array allocator-aware (and add doctest) stabilize feature int_lowest_highest_one stabilize feature isolate_most_least_significant_one stabilize feature uint_bit_width Cargo clean: add target directory validation manifest: allow git dependency alongside alternate registry auth: add auth scheme hint to token rejected error for alt registries core: use closest_msg to suggest similar member name for mistyped -p lints: ignore unused_crate_dependencies status toml: force script edition warnings on quiet copy cargo clean target-dir validation tests to clean_new_layout.rs never include use extra-filename in build scripts support target.'cfg(..)'.rustdocflags analogously to rustflags Rustdoc fix pattern types rendering dep-info for standalone markdown inputs inherit inline attributes for declarative macros Clippy fn_to_numeric_cast_any: do not warn cast to raw pointer even more fixes for handling of macros extend manual_filter to cover and_then fix unused_async false positive for stubs with args fix wrong suggestion for println_empty_string with non-parenthesis delimiters truncate constants to target type in comparison Rust-Analyzer changes to build scripts and config.toml should always refresh demoting completion relevance when an inherent impl already exists enhance runnable command placeholders support impl and mut restrictions fix [env] in .cargo/config.toml overriding process environment variables fix rustfmt relative custom command MIR evaluation of sized &T with recursive const fn check coercion, not unification, in "Fill struct fields", as the criteria to use an existing local as the field's value complete variants of hidden enums through public aliases consider the context of the path for ImportAssets diagnose cfged-out crate disable the fix for missing-fields when the fields are private enable vscode suggest in strings fix ref_match position when keyword prefix improve add some on block like expression improve label on add_missing_match_arms assist no complete term expressions on qualified path no deref index-expr for extract_function no imports on type anchor qualified path parse cfg_attr and cfg specially handle token mutability in edit flow as well migrate extract struct from enum variant to new SyntaxEditor and Port whitespace heuristics to SyntaxEditor replace make from generate single field struct from with SyntaxFactory unwrap unnecessary result return type in view_crate_graph Rust Compiler Performance Triage This week was negative, mainly caused by a type system fix and because we had to temporarily revert some attribute cleanups that previously improved performance. Triage done by @panstromek. Revision range: e73c56ab..dab8d9d1 Summary: (instructions:u) mean range count Regressions ❌ (primary) 0.4% [0.2%, 0.7%] 46 Regressions ❌ (secondary) 0.5% [0.1%, 2.3%] 102 Improvements ✅ (primary) -0.5% [-0.6%, -0.4%] 4 Improvements ✅ (secondary) -0.4% [-0.6%, -0.2%] 5 All ❌✅ (primary) 0.4% [-0.6%, 0.7%] 50 4 Regressions, 1 Improvement, 5 Mixed; 6 of them in rollups 41 artifact comparisons made in total Full report here Approved RFCs Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: No RFCs were approved this week. Final Comment Period Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. Tracking Issues & PRs Rust Verify that penultimate segment of enum variant path refers to enum if it has args deprecate std::char constants and functions impl Default for RepeatN Make std::fs::File Send on UEFI Cargo feat(config): Stabilize resolver.lockfile-path config Compiler Team (MCPs only) Optimize repr(Rust) enums by omitting tags in more cases involving uninhabited variants. Proposal for a dedicated test suite for the parallel frontend Promote tier 3 riscv32 ESP-IDF targets to tier 2 Proposal for Adapt Stack Protector for Rust Rust RFCs Propose the Rust Foundation Maintainer fund Leadership Council Fund the Content team (2026 allocation) No Items entered Final Comment Period this week for Language Reference, Language Team or Unsafe Code Guidelines. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list. New and Updated RFCs No New or Updated RFCs were created this week. Upcoming Events Rusty Events between 2026-04-15 - 2026-05-13 🦀 Virtual 2026-04-15 | Hybrid (Vancouver, BC, CA) | Vancouver Rust Nushell 2026-04-15 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-04-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group April, 2026 SRUG (Seattle Rust User Group) Meetup 2026-04-19 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Rust Deep Learning: Third Sunday 2026-04-21 | Virtual (Washington, DC, US) | Rust DC Mid-month Rustful 2026-04-22 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-04-23 | Virtual (Amsterdam, NL) | Bevy Game Development Bevy Meetup #13 2026-04-23 | Virtual (Berlin, DE) | Rust Berlin Rust Hack and Learn 2026-04-24 | Virtual (Nairobi, KE) | RustaceansKenya Transitioning To Rust: The Learning Curve 2026-04-28 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Fourth Tuesday 2026-04-28 | Virtual (London, UK) | Women in Rust Lunch & Learn: From Protobuf to Production - A Guide to gRPC in Rust 2026-04-29 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-05-01 | Virtual (Nürnberg, DE) | Rust Nuremberg Hacker's Hike 0x1 2026-05-02 | Virtual (Kampala, UG) | Rust Circle Meetup Rust Circle Meetup 2026-05-03 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Rust Deep Learning: First Sunday 2026-05-06 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-05-06 | Virtual (Indianapolis, IN, US) | Indy Rust Indy.rs - with Social Distancing 2026-05-07 | Virtual (Berlin, DE) | Rust Berlin Rust Hack and Learn 2026-05-07 | Virtual (Nürnberg, DE) | Rust Nuremberg Rust Nürnberg online 2026-05-12 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Second Tuesday 2026-05-12 | Virtual (London, GB) | Women in Rust 👋 Community Catch Up 2026-05-13 | Virtual (Girona, ES) | Rust Girona Weekly coding session Asia 2026-04-17 | Bangalore, IN | Rust India Rust India Workshop 2026-04-18 | Bangalore, IN | Rust India Rust India Conference 2026-05-13 | Malaysia, MY | Rust Meetup Malaysia Rust Meetup Malaysia Europe 2026-04-16 | Berlin, DE | Rust Berlin Rust Berlin on location 🏳️‍🌈 - Edition 013 2026-04-21 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig Native GUIs with Rust 2026-04-23 | Aarhus, DK | Rust Aarhus Talk Night and Birthday Party at MFT Energy 2026-04-24 - 2026-04-26 | Augsburg, DE | Rust Meetup Augsburg Future Week Augsburg: Road to Game Jam – Spielend Bevy und Rust lernen bei Tuxedo Computers 2026-04-25 | Stockholm, SE | Stockholm Rust Ferris' Fika Forum #26 2026-04-29 | Paris, FR | Paris Rustaceans Rust Meetup in Paris 2026-04-30 | Manchester, GB | Rust Manchester Rust Manchester April Talk 2026-05-02 | Augsburg, DE | Rust Munich and Rust Augsburg Augsburger Linux-Infotag 2026: Gemeinschaftsstand Rust Augsburg und Rust München 2026-05-04 | Amsterdam, NH, NL | Rust Developers Amsterdam Group Rust Meetup @ JetBrains 2026-05-04 | Frankfurt, DE | Rust Rhein-Main Writing a stock portfolio simulation in Rust with Leptos 2026-05-05 | Olomouc, CZ | Rust Moravia 5. Rust Moravia Meetup (Ukaž testy!) North America 2026-04-15 | Hybrid (Vancouver, BC, CA) | Vancouver Rust Nushell 2026-04-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group April, 2026 SRUG (Seattle Rust User Group) Meetup 2026-04-16 | Mountain View, CA, US | Hacker Dojo RUST MEETUP at HACKER DOJO 2026-04-16 | Nashville, TN, US | Music City Rust Developers Community Meetup 2026-04-18 | Boston, MA, US | Boston Rust Meetup Harvard Square Rust Lunch, Apr 18 2026-04-20 - 2026-04-22 | Portland, OR | Tokio TokioConf 2026 2026-04-21 | San Francisco, CA, US | San Francisco Rust Study Group Rust Hacking in Person 2026-04-22 | Austin, TX, US | Rust ATX Rust Lunch - Fareground 2026-04-22 | New York, NY, US | Rust NYC Rust NYC: Formally Verified Rust & SAT Solvers 2026-04-22 | Portland, OR | Apache DataFusion Meetup Portland Apache DataFusion Meetup 2026-04-23 | Los Angeles, CA, US | Rust Los Angeles Rust LA April! 2026-04-25 | Boston, MA, US | Boston Rust Meetup South Station Rust Lunch, Apr 25 2026-04-28 | New York, NY, US | Rust NYC Rust NYC x OpenAI: Safer 'unsafe' & Barnum: The agentic workflow engine. 2026-04-30 | Atlanta, GA, US | Rust Atlanta Rust-Atl 2026-05-07 | Saint Louis, MO, US | STL Rust Open Project Night South America 2026-04-17 | Rio de Janeiro, BR | Meetups Rust RJ Meetup Rust RJ If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access. Jobs Please see the latest Who's Hiring thread on r/rust Quote of the Week the amount of times that I spend 15 min in the docs + coding which end up in a monstrous or().flatten().map().is_ok_and() only to get slapped by clippy saying replace your monster with this single function please is way too high 😀 – Teufelchen on RIOT off-topic matrix chat Thanks to chrysn for the suggestion! Please submit quotes and vote for next week! This Week in Rust is edited by: nellshamrell llogiq ericseppanen extrawurst U007D mariannegoldin bdillo opeolluwa bnchi KannanPalani57 tzilist Email list hosting is sponsored by The Rust Foundation Discuss on r/rust

Mozilla Privacy Blog: Mozilla Urges the FTC to Tackle Harmful Design Practices

Wed, 15 Apr 2026 18:29:36 +0200

In response to concerns from both consumers and the industry, the US Federal Trade Commission (FTC) invited public comment on whether it should amend the current Rule Concerning the Use of Prenotification Negative Option Plans to address deceptive or unfair negative option practices. Negative option marketing is a practice in which a seller treats a consumer’s silence or failure to take action as consent to be charged for goods or services. This technique is often used in subscription services, where users may be guided toward accepting recurring charges through default selections or obscure disclosures. These design practices, also known as “dark patterns,” successfully manipulate and influence user behavior on a systematic level and are often employed in all aspects of digital markets, not just with subscriptions. As a browser developer, Mozilla is well-acquainted with the negative impacts of manipulative design. The web browser market provides a documented case study illustrating how operating systems deploy deceptive design practices to weaponize friction and status-quo bias to influence consumer behavior. As such, Mozilla was eager to provide feedback and encourage the Commission to examine the breadth of deceptive design practices that undermine choice. Dark patterns are a byproduct of power asymmetry between companies and consumers. If we don’t protect meaningful choice and effective competition now, we risk giving even more control to the biggest players — and losing what makes the web open and innovative in the first place. The FTC has a critical opportunity, both in this rulemaking and more broadly, to modernize consumer protection for the realities of digital markets. We encourage the FTC to: Make clear that practices which manipulate, coerce, or mislead users through interface design, defaults, or friction fall within the scope of unfair or deceptive acts or practices. Investigate remedies for digital markets to operate with meaningful consumer choice. Prioritize targeted enforcement against well-documented uses of deceptive design, such as tactics prevalent on the Windows operating system, designed to push users to the Edge browser. We welcome the opportunity to share our relevant experiences in the browser space and look forward to continuing the conversation. Read our full comments to the FTC for more details on our recommendations. The post Mozilla Urges the FTC to Tackle Harmful Design Practices appeared first on Open Policy & Advocacy.

Mozilla Privacy Blog: Mozilla Urges the FTC to Tackle Harmful Design Practices

Wed, 15 Apr 2026 18:29:36 +0200

Firefox Tooling Announcements: Happy BMO Push Day! (20260415.1)

Wed, 15 Apr 2026 23:29:30 +0200

Github Link The following changes have been pushed to bugzilla.mozilla.org: Bug 2023761 - [GITHUB] Allow use of individual api keys for pull requests and push comments instead of single share secret Bug 2012634 - “Phabricator Revisions” table overflows on X axis on mobile Bug 2028222 - Pasting multi-line text after selecting multi-line text does not overwrite, but applies markup for link Bug 2029522 - CI workflow uses deprecated docker-compose v1 and actions/checkout@v3 Bug 2031520 - Missing space in “Throw away my changes, andrevisit bug NNN” message (when marking a bug as a duplicate of a hidden bug) Bug 2030581 - REST API: PUT /rest/bug/attachment/{id} does not pass is_markdown when adding comment Bug 2018260 - “Fields You Can Search On” is blocking people from making it through quicksearch.html doc Bug 2028240 - Cloned security bugs should default to being secure Bug 2031007 - When linking a Github pull request to a BMO bug, the attachment filename should contain the repository name in addition to the pull request ID Discuss these changes in the BMO Matrix Room 1 post - 1 participant Read full topic

The Rust Programming Language Blog: Announcing Rust 1.95.0

Thu, 16 Apr 2026 02:00:00 +0200

The Rust team is happy to announce a new version of Rust, 1.95.0. Rust is a programming language empowering everyone to build reliable and efficient software. If you have a previous version of Rust installed via rustup, you can get 1.95.0 with: $ rustup update stable If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.95.0. If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across! What's in 1.95.0 stable cfg_select! Rust 1.95 introduces a cfg_select! macro that acts roughly similar to a compile-time match on cfgs. This fulfills the same purpose as the popular cfg-if crate, although with a different syntax. cfg_select! expands to the right-hand side of the first arm whose configuration predicate evaluates to true. Some examples: cfg_select! { unix => { fn foo() { /* unix specific functionality */ } } target_pointer_width = "32" => { fn foo() { /* non-unix, 32-bit functionality */ } } _ => { fn foo() { /* fallback implementation */ } } } let is_windows_str = cfg_select! { windows => "windows", _ => "not windows", }; if-let guards in matches Rust 1.88 stabilized let chains. Rust 1.95 brings that capability into match expressions, allowing for conditionals based on pattern matching. match value { Some(x) if let Ok(y) = compute(x) => { // Both `x` and `y` are available here println!("{}, {}", x, y); } _ => {} } Note that the compiler will not currently consider the patterns matched in if let guards as part of the exhaustiveness evaluation of the overall match, just like if guards. Stabilized APIs MaybeUninit: From MaybeUninit: AsRef MaybeUninit: AsRef MaybeUninit: AsMut MaybeUninit: AsMut [MaybeUninit; N]: From Cell: AsRef Cell: AsRef Cell: AsRef bool: TryFrom AtomicPtr::update AtomicPtr::try_update AtomicBool::update AtomicBool::try_update AtomicIn::update AtomicIn::try_update AtomicUn::update AtomicUn::try_update cfg_select! mod core::range core::range::RangeInclusive core::range::RangeInclusiveIter core::hint::cold_path ::as_ref_unchecked ::as_ref_unchecked ::as_mut_unchecked Vec::push_mut Vec::insert_mut VecDeque::push_front_mut VecDeque::push_back_mut VecDeque::insert_mut LinkedList::push_front_mut LinkedList::push_back_mut Layout::dangling_ptr Layout::repeat Layout::repeat_packed Layout::extend_packed These previously stable APIs are now stable in const contexts: fmt::from_fn ControlFlow::is_break ControlFlow::is_continue Destabilized JSON target specs Rust 1.95 removes support on stable for passing a custom target specification to rustc. This should not affect any Rust users using a fully stable toolchain, as building the standard library (including just core) already required using nightly-only features. We're also gathering use cases for custom targets on the tracking issue as we consider whether some form of this feature should eventually be stabilized. Other changes Check out everything that changed in Rust, Cargo, and Clippy. Contributors to 1.95.0 Many people came together to create Rust 1.95.0. We couldn't have done it without all of you. Thanks!

Mozilla Localization (L10N): Localizer Spotlight: Baurzhan

Thu, 16 Apr 2026 00:38:25 +0200

About you My name is Baurzhan Muftakhidinov. I’m from Kazakhstan. I speak Kazakh, Russian, English and I have been contributing to Mozilla localization for more than 18 years. From Linux Curiosity to Mozilla Localization Q: How did you get involved in localization, and what drew you to Mozilla? A: I came to Mozilla through Linux during my student years. I became interested in Linux at university, and very quickly I noticed how closely the open source world was connected: where there was Linux, Firefox was usually nearby. When installing Linux distributions, one of the first things I noticed was language support. Many languages were available, but Kazakh was often missing or only partially supported. That made me ask a simple question: why is that, and what can be done about it? Through Ubuntu’s CD distribution program, I discovered Launchpad and began translating Firefox there. Around the same time, through a local Linux forum, I connected with Timur Timirkhanov, who already had experience with Mozilla localization. He helped me understand Mozilla’s processes, pointed me to packages that needed translation, and opened a locale registration ticket for Kazakh in Bugzilla. Soon after, Dauren Sarsenov joined, and in the beginning it was mainly the two of us working on Firefox. When Kazakh first appeared in a Firefox beta in spring 2009, we were extremely proud. It felt like a real milestone — not just translating isolated strings, but seeing a major global product appear in Kazakh. For me, that was bigger than one browser. At the time, we were dreaming about a fully usable open source desktop in Kazakh, and Mozilla localization became one important part of that larger goal. What started as curiosity became a long-term commitment: making technology more accessible in Kazakh and proving that our language belongs in modern software. Q: Which Mozilla products are closest to you? Do you use them regularly? A: Firefox is definitely the product closest to me because I use it every day — both desktop and mobile. It never feels like I am translating something distant from my real life. I see the interface, the wording choices, and the practical impact of localization almost daily. What makes Firefox especially meaningful is that it is both symbolic and practical. Symbolically, it showed that Kazakh could be present in one of the most important pieces of everyday software. Practically, it gave users a browser they could use in their own language. A browser is the gateway to the internet, so localizing Firefox means much more than translating one application. I also use Thunderbird from time to time and visit MDN quite often. Even when I am not translating, I interact with Mozilla products as a user, so there is always a natural connection between volunteer work and daily habits. People around me know me through Firefox localization more than through anything else. Very often I am simply “the person who translated Firefox into Kazakh.” That says a lot about how visible Firefox has been. Promoting Kazakh Localization and Building an Ecosystem Q: How have you promoted Kazakh-localized software? A: Most of my promotion work has been grassroots. In earlier years, I shared updates on Linux and open source forums, especially communities already interested in free software. Even when people were not personally interested in contributing, many showed strong support and encouragement. That confirmed that localization mattered beyond just the translation team. One of my bigger efforts was creating a Debian-based Linux distribution from 2012 to 2015 called Kazsid. I built it partly to test how Kazakh localization worked across multiple applications in a real desktop environment. I included programs that already had Kazakh translations — Firefox, LibreOffice, desktop environments, and other tools — set Kazakh as the default language, and tested how everything worked together. I shared the builds on forums, and some people downloaded and tried them. It was one of the most practical ways I encouraged interest in Linux and localized software. Later, as translations matured upstream, maintaining a separate distribution was no longer necessary. That was actually a positive sign — users could install standard distributions and get the same localized experience. Today I post updates on LinkedIn. It helps maintain visibility, even if it does not often bring in new contributors. Working Independently — and Working Systematically Q: What does the Kazakh localization community look like today? A: At the moment, I am effectively the only active contributor across several major open source localization efforts in Kazakh, including Mozilla products, LibreOffice, GNOME, Xfce, and others. In the early years, several people made meaningful contributions, but most eventually moved on. Timur helped significantly, especially in the earlier stages and in understanding Mozilla’s processes, and I still occasionally consult trusted people when I need a second opinion. The challenge for smaller languages is not only starting a translation but maintaining it over the long term. From early on, I was not thinking about one application. My goal was broader: to help create a real open source desktop experience in Kazakh. A browser translated into Kazakh is important, but a full ecosystem is even more meaningful. Sustainability is the hardest part. Q: How do you approach quality when you are the main translator? A: Direct user feedback is rare. So QA depends largely on my own testing, judgment, and systems. I test software in real use, especially Firefox. In earlier years, I also used Nightly builds. Before settling on new terminology, I check dictionaries and reference materials. I consult fluent speakers when needed, and sometimes I discuss wording with my wife to see how natural it sounds. My principle is that translations should feel clear and alive, not mechanically imported. I studied in Kazakh and remember the terms we were actually taught in IT-related subjects, and that background matters to me. Because of my scripting background, I have written small tools in Python to help verify translations, track terminology, and maintain consistency. QA is not just “reading it once and hoping for the best.” It is a combination of linguistic judgment, real usage, consultation, and automated checking. More recently, I have been exploring how AI can assist localization. By testing translations through tools like the Google Gemini API and guiding terminology carefully, I have been able to close significant translation gaps. For Kazakh, newer models understand context much better than traditional machine translation systems. AI does not replace judgment, but it can make the work faster and more effective. Professional Background Q: How does your professional background influence your localization work? Baurzhan at GIS Day 2025 A: My background is partly technical and partly analytical. I studied IT, worked as a Linux system administrator, and later moved into data analysis and GIS. Those technical skills helped significantly. Automation makes a long-term localization effort much more manageable, especially when one person is doing most of the work. Localization has strengthened my discipline and consistency. It requires patience and regular effort. Over time, I developed an instinct for terminology and phrasing — whether a term feels natural or artificial in context. A Few Personal Notes I have loved reading since I was four years old. My favorite genres are science fiction and popular science. Reading is still how I recharge. I have lived in several cities in Kazakhstan, so I sometimes joke that I am a true nomad. My family has always been supportive of my open source work. And when I run into a particularly difficult translation, I can still discuss it with my wife and get a fresh perspective.

Firefox Developer Experience: Firefox WebDriver Newsletter 150

Tue, 21 Apr 2026 16:01:09 +0200

WebDriver is a remote control interface that enables introspection and control of user agents. As such, it can help developers to verify that their websites are working and performing well with all major browsers. The protocol is standardized by the W3C and consists of two separate specifications: WebDriver classic (HTTP) and the new WebDriver BiDi (Bi-Directional). This newsletter gives an overview of the work we’ve done as part of the Firefox 150 release cycle. Contributions Firefox is an open source project, and we are always happy to receive external code contributions to our WebDriver implementation. We want to give special thanks to everyone who filed issues, bugs and submitted patches. In Firefox 150, Khalid AlHaddad contributed several improvements: Added a new test to check that viewport dimentions are correct immediately after browsingContext.create resolves. And more test improvements: Asynchronous tests now consistently use pytest asyncio markers. Introduced a new fixture to install WebExtensions and automatically uninstall them at the end of the test. Updated the helper for waiting on BiDi events to use a timeout multiplier, and migrated it to a fixture. WebDriver code is written in JavaScript, Python, and Rust so any web developer can contribute! Read how to setup the work environment and check the list of mentored issues for Marionette, or the list of mentored JavaScript bugs for WebDriver BiDi. Join our chatroom if you need any help to get started! General Fixed an issue where pending downloads could block browser shutdown due to a confirmation prompt. The prompt is now dismissed automatically. WebDriver BiDi Added the emulation.setNetworkConditions command, which supports the type: offline at the moment. Using this, you can emulate offline mode either on specific browsing contexts, on user contexts (a.k.a. containers) or globally. Improved handling of non utf-8 header values across network module commands and events. These are now correctly serialized as BytesValue. Fixed an issue where download events triggered by responses with a “Content-Disposition” header were missing the navigation property when initiated from a link with target="_blank". Updated the log.entryAdded event so it is only emitted for console API calls that produce a visible output in developer tools (see also the console specification: using the printer). Calls such as console.clear or console.time no longer trigger an event. Fixed a race condition in browsingContext.setViewport which could cause timeouts when multiple contexts were created in parallel. Improved browsingContext.locateNodes to allow retrieval of the HTML element (documentElement) of a page when using the css locator. Marionette Fixed the WebDriver:getShadowRoot command to no longer return user-agent shadow roots.

The Mozilla Blog: The zero-days are numbered

Tue, 21 Apr 2026 20:29:17 +0200

Since February, the Firefox team has been working around the clock using frontier AI models to find and fix latent security vulnerabilities in the browser. We wrote previously about our collaboration with Anthropic to scan Firefox with Opus 4.6, which led to fixes for 22 security-sensitive bugs in Firefox 148. As part of our continued collaboration with Anthropic, we had the opportunity to apply an early version of Claude Mythos Preview to Firefox. This week’s release of Firefox 150 includes fixes for 271 vulnerabilities identified during this initial evaluation. As these capabilities reach the hands of more defenders, many other teams are now experiencing the same vertigo we did when the findings first came into focus. For a hardened target, just one such bug would have been red-alert in 2025, and so many at once makes you stop to wonder whether it’s even possible to keep up. Our experience is a hopeful one for teams who shake off the vertigo and get to work. You may need to reprioritize everything else to bring relentless and single-minded focus to the task, but there is light at the end of the tunnel. We are extremely proud of how our team rose to meet this challenge, and others will too. Our work isn’t finished, but we’ve turned the corner and can glimpse a future much better than just keeping up. Defenders finally have a chance to win, decisively. Until now, the industry has largely fought security to a draw. Vendors of critical internet-exposed software like Firefox take security extremely seriously and have teams of people who get out of bed every morning thinking about how to keep users safe. Nevertheless, we’ve all long quietly acknowledged that bringing exploits to zero was an unrealistic goal. Instead, we aimed to make them so expensive that only actors with functionally unlimited budgets can afford them, and that the cost of burning such an expensive asset disincentivizes those actors against casual use. This is because security to date has been offensively-dominant: the attack surface isn’t infinite, but it’s large enough to be difficult to defend comprehensively with the tools we’ve had available. This gives attackers an asymmetric advantage, since they only need to find one chink in the armor. We use defense-in-depth to apply multiple layers of overlapping defenses, but no layer is bulletproof. Firefox runs each website in a separate process sandbox, but attackers try to combine bugs in the rendering code with bugs in the sandbox to escape to a more privileged context. We’ve led the industry in building and adopting Rust, but we still can’t afford to stop everything to rewrite decades of C++ code, especially since Rust only mitigates certain (very common) classes of vulnerabilities. We pair defense-in-depth engineering with an internal red team tasked with staying on the leading edge of automated analysis techniques. Until recently, these have largely been dynamic analysis techniques like fuzzing. Fuzzing is quite fruitful in practice, but some parts of the code are harder to fuzz than others, leading to uneven coverage. Elite security researchers find bugs that fuzzers can’t largely by reasoning through the source code. This is effective, but time-consuming and bottlenecked on scarce human expertise. Computers were completely incapable of doing this a few months ago, and now they excel at it. We have many years of experience picking apart the work of the world’s best security researchers, and Mythos Preview is every bit as capable. So far we’ve found no category or complexity of vulnerability that humans can find that this model can’t. This can feel terrifying in the immediate term, but it’s ultimately great news for defenders. A gap between machine-discoverable and human-discoverable bugs favors the attacker, who can concentrate many months of costly human effort to find a single bug. Closing this gap erodes the attacker’s long-term advantage by making all discoveries cheap. Encouragingly, we also haven’t seen any bugs that couldn’t have been found by an elite human researcher. Some commentators predict that future AI models will unearth entirely new forms of vulnerabilities that defy our current comprehension, but we don’t think so. Software like Firefox is designed in a modular way for humans to be able to reason about its correctness. It is complex, but not arbitrarily complex1. The defects are finite, and we are entering a world where we can finally find them all. 1 There’s a risk that codebases begin to surpass human comprehension as a result of more AI in the development process, scaling bug complexity along with (or perhaps faster than) discovery capability. Human-comprehensibility is an essential property to maintain, especially in critical software like browsers and operating systems. The post The zero-days are numbered appeared first on The Mozilla Blog.

Niko Matsakis: Symposium: community-oriented agentic development

Tue, 21 Apr 2026 18:24:17 +0200

I’m very excited to announce the first release of the Symposium project as well as its inclusion in the Rust Foundation’s Innovation Lab. Symposium’s goal is to let everyone in the Rust community participate in making agentic development better. The core idea is that crate authors should be able to vend skills, MCP servers, and other extensions, in addition to code. The Symposium tool then installs those extensions automatically based on your dependencies. After all, who knows how to use a crate better than the people who maintain it? If you want to read more details about how Symposium works, I refer you to the announcement post from Jack Huey on the main Symposium blog. This post is my companion post, and it is focused on something more personal – the reasons that I am working on Symposium. I believe in extensibility everywhere The short version is that I believe in extensibility everywhere. Right now, the Rust language does a decent job of being extensible: you can write Rust crates that offer new capabilities that feel built-in, thanks to proc-macros, traits, and ownership. But we’re just getting started at offering extensibility in other tools, and I want us to hurry up! I want crate authors to be able to supply custom diagnostics. I want them to be able to supply custom lints. I want them to be able to supply custom optimizations. I want them to be able to supply custom IDE refactorings. And, as soon as I started messing around with agentic development, I wanted extensibility there too. Symposium puts crate authors in charge The goal of Symposium is to give crate authors, and the broader Rust community, the ability to directly influence the experience of people writing Rust code with agents. Rust is a really popular target language for agents because the type system provides strong guardrails and it generates efficient code – and I predict it’s only going to become more popular. Despite Rust’s popularity as an agentic coding target, the Rust community right now are basically bystanders when it comes to the experience of people writing Rust with agents; I want us to have a means of influencing it directly. Enter Symposium. With Symposium, Crate authors can package up skills etc and then Symposium will automatically make them available for your agent. Symposium also takes care of bridging the small-but-very-real gaps between agents (e.g., each has their own hook format, and some of them use .agents/skills and some use .claude/skills, etc). Example: the assert-struct crate Let me give you an example. Consider the assert-truct crate, recently created by Carl Lerche. assert-struct lets you write convenient assertions that test the values of specific struct fields: assert_struct!(val, _ { items: [1, 2, ..], tags: #("a", "b", ..), .. }); The problem: agents don’t know about it This crate is neat, but of course, no models are going to know how to use it – it’s not part of their training set. They can figure it out by reading the docs, but that’s going to burn more tokens (expensive, slow, consumes carbon), so that’s not a great idea. You could teach the agent how to use it… In practice what people do today is to add skills to their project – for example, in his toasty crate, Carl has a testing skill that also shows how to use assert-struct. But it seems silly for everybody who uses the crate to repeat that content. …but wouldn’t it be better the crate could teach the agent itself? With Symposium, teaching your agent how to use your dependencies should not be necessary. Instead, your crates can publish their own skills or other extensions. The way this works is that the assert-struct crate defines the skill once, centrally, in its own repository1. Then there is a separate file in Symposium’s central recommendations repository with a pointer to the assert-struct repository. Any time that the assert-struct repository updates that skill, the updates are automatically synchronized for you. Neat! (You can also embed skills directly in the rr repository, but then updating them requires a PR to that repo.) Frequently asked questions How do I add support for my crate to Symposium? It’s easy! Check out the docs here: https://symposium.dev/crate-authors/supporting-your-crate.html What kind of extensions does Symposium support? Skills, hooks, and MCP Servers, for now. Why does Symposium have a centralized repository? Currently we allow skill content to be defined in a decentralized fashion but we require that a plugin be added to our central recommendations repository. This is a temporary limitation. We eventually expect to allow crate authors to adds skills and plugins in a fully decentralized fashion. We chose to limit ourselves to a centralized repository early on for three reasons: Even when decentralized support exists, a centralized repository will be useful, since there will always be crates that choose not to provide that support. Having a central list of plugins will make it easy to update people as we evolve Symposium. Having a centralized repository will help protect against malicious skills[^threat] while we look for other mechanisms, since we can vet the crates that are added and easily scan their content. What if I want to add skills for crates private to my company? I don’t want to put those in the central repository! No problem, you can add a custom plugin source. Are you aware of the negative externalities of LLMs? I am, very much so. I feel like a lot of the uses of LLMs we see today are not great (e.g., chat bots hijack conversational and social cues to earn trust that they don’t deserve) and to reconfirm peoples’ biases instead of challenging their ideas. And I’m worried about the environmental cost of data centers and the way companies have retreated from their climate goals. And I don’t like how centralized models concentrate economic power.2 So yeah, I see all that. And I also see how LLMs enable people to build things that they couldn’t build before and help to make previously intractable problems soluble – and that includes more and more people who never thought of themselves as programmers3. My goal with Symposium and other projects is to be part of the solution, finding ways to leverage LLMs that are net positive: opening doors, not closing them. Extensibility: because everybody has something to offer Fundamentally, the reason I am working on Symposium is that I believe everybody has something unique to offer. I see the appeal of strongly opinionated systems that reflect the brilliant vision of a particular person. But to me, the most beautiful systems are the ones that everybody gets to build together4. This is why I love open source. This is why I love emacs5. It’s why I love VSCode’s extension system, which has so many great gems6. To me, Symposium is a double win in terms of empowerment. First, it makes agents extensible, which is going to give crate authors more power to support their crates. But it also helps make agentic programming better, which I believe will ultimately open up programming to a lot more people. And that is what it’s all about. Actually as of this posting, the assert-struct skill is embedded directly in the recommendations repo. But I opened a PR to put it on assert-struct and I’ll port it over once it lands. ↩︎ I’m very curious to do more with open models. ↩︎ Within Amazon, it’s been amazing to watch how many people who never thought of themselves as software developers are starting to build software. Considering the challenges the software industry has with representation, I find this very encouraging. Diverse teams are stronger, better teams! ↩︎ None of this is to say I don’t believe in good defaults; there’s a reason I use Zed and VSCode these days, and not emacs, much as I love it in concept. ↩︎ OMG. One of my friends college wrote this amazing essay some time back on emacs. Next time you’re doomscrolling on the toilet or whatever, pop over to this essay instead. Fair warning, it’s long, so it’ll take you a while to read, but I think it nails what people love about emacs. ↩︎ These days I’m really enjoying Zed, but I have to say, I really miss kahole/edamagit! Which of course is inspired by the magit emacs package. ↩︎

The Mozilla Blog: What’s new in Firefox mobile: Less clutter, more control and a free built-in VPN

Tue, 21 Apr 2026 21:36:46 +0200

Mobile browsing hasn’t kept up with how people actually use their phones. Right now, even basic tasks can feel harder than they should. Finding what you need can mean scrolling through ads and filler content, keeping track of too many tabs, or thinking twice about how private your connection is. A mobile browser should do more — and we’re raising the bar. Firefox is rolling out a set of updates that build on our most popular desktop features and adapt them for how you browse on-the-go. Here’s what’s out now, and what’s coming next. Get the key points with Shake to Summarize When you’re following a recipe, reading a product review, or deciding whether a long article is worth your time, getting to the useful part can take longer than it should. With Shake to Summarize, you can shake or tap your phone to generate a quick summary of the page. Currently available for iOS users in English, we’re expanding availability to all iOS users in German, French, Spanish, Portuguese, Italian and Japanese starting with Firefox 150 on April 21. We’ll also soon be making Shake to Summarize available to Android users in English, so they too can get to the key points of any article in seconds. Take control of how AI shows up AI features are becoming a more common part of browsers — but not everyone wants the same experience. Firefox gives you a say in how they’re used. With AI Controls, you can turn AI features off entirely, enable only the ones you want, or adjust things over time. Rolling out on Android and iOS beginning May 21. Stay protected with a free, built-in VPN Firefox’s free built-in VPN covers up to 50 gigabytes of your browsing in Firefox each month, across desktop and mobile devices. It adds a layer of protection to your browsing activity by masking your IP address – especially useful when you’re on public Wi-Fi. Unlike many “free VPNs” that rely on ads or selling user data to generate revenue, Firefox is built with a different model: no selling your browsing data, no injecting ads into your traffic. Instead, we offer a limited amount of browser-level protection for free, alongside Mozilla VPN, our paid, unlimited, full-device VPN service. Rolling out on Android soon. Keep your tabs organized with Tab Groups Tab Groups have been among the most-requested mobile features from our Mozilla community, and they’re coming on mobile soon. You’ll be able to group related tabs to stay organized, whether you’re comparing restaurants, planning a trip or saving articles to read later. We’re also building toward smart groupings, where Firefox can automatically suggest tab groups for you. Rolling out on Android soon. More updates, built around how you browse on mobile Your phone comes with a browser. That doesn’t mean it has to stay your default “Firefox exists to give people a better way to experience the web, and that has to be just as true on mobile as it is on desktop,” said Ajit Varma, head of Firefox. “For many people, their phone is their primary way of getting online, and they deserve a browser that’s fast, intuitive and built around their needs. That’s why we’re investing in mobile more than ever before. We’re building for the millions of people who choose Firefox every day, and giving even more people a reason to do the same.” Firefox is building a mobile experience designed around how people browse — with tools that help you move faster, stay organized and stay in control. These updates begin rolling out in April with more on the way. Take Firefox with you Download Firefox mobile The post What’s new in Firefox mobile: Less clutter, more control and a free built-in VPN appeared first on The Mozilla Blog.

Mozilla Data YouTube Channel: Data Incident Process

Wed, 22 Apr 2026 01:46:50 +0200

Mike Droettboom talks about Data @ Mozilla's process for handling incidents.

Mozilla Performance Blog: Telemetry Alerting Beta Announcement

Tue, 21 Apr 2026 21:58:30 +0200

We’re happy to announce that the Telemetry Alerting beta is now open to everyone! Monitoring for changes in telemetry probes that you own can be difficult to do on a regular and continuous basis. With telemetry alerting, that changes today! You can now quickly set up your timing distribution probes for automated monitoring on Windows with notifications through email or a Bugzilla bug. To get started, if you only need email alerts, simply add monitor: True to the metadata section of your probe (example). Example of an email alert. If you would prefer to receive Bugzilla bugs when a change is detected, set the monitor field like so (example): monitor: alert: True lower_is_better: True/False # Optional bugzilla_notification_emails: - Example of an alert bug. More information about telemetry alerting, and how to set up a probe can be found here in the documentation. There’s also a dashboard that can show you all of the existing telemetry alerts along with some detection information. For now, we only support change detection on Windows for `timing_distribution` probes (see here for other desktop platforms, and android). Please note that this is an open beta and we are actively looking for feedback on this system. If you hit any issues, or have any suggestions feel free to file a bug in the Testing :: Performance component or reach out to us in either #perf-help on Slack or in #perftest on Matrix. Special thanks to Eduardo Filho for his support on the telemetry probe side, to Bas Schouten for his guidance and work on the CDF Squared detection technique, and to Andrej Glavic and Beatrice Acasandrei for their help in reviewing the Treeherder changes. For a more detailed look at how this works, see this blog post.

This Week In Rust: This Week in Rust 648

Wed, 22 Apr 2026 06:00:00 +0200

Mozilla Performance Blog: Telemetry Alerting: How It Works

Wed, 22 Apr 2026 02:40:11 +0200

We recently released the telemetry alerting beta, and announced it in the blog post here! This blog post will dive into the details of how it works across Treeherder, and Mozdetect. At a high level, MozDetect handles the change point detection for telemetry probes, and Treeherder handles storing the detections, and producing the emails/bugs for these. MozDetect All of the existing, and any future change detection point techniques used for telemetry alerting are built in MozDetect. Having these live outside of Treeherder gives a low-barrier to entry for adding new features, and testing existing ones without having to set up everything needed for alerting in Treeherder. It’s built as a python module that is run through uv. This makes it very easy for anyone to run the code because of uv’s excellent python version, and dependency management. How to work with the code in this repository is outlined here, along with how to add your own techniques to it (note the access to mozdata through gcloud is required for this). Detectors are split into two parts: (i) a detector that performs a comparison between two groups, and (ii) a detector that performs detection on a time series (using the detector from (i)). Our default detection technique, called cdf_squared lives here. The timeseries_detector_name is the name that will be used to access the detector from the telemetry probe side through the change_detection_technique field. The only method that absolutely needs to be implemented by these is the detect_changes method and it must return a list of Detection objects. These detection objects contain all the necessary information for producing an alert. There is also an optional_detection_info field that can contain additional things like attachments that would be added to Bugzilla bugs, and additional_data that can hold JSON data for storage in the DB. The cumulative distribution function (CDF) squared technique uses these to store the CDF before and after the detection along with a graph of these as an attachment for the Bugzilla bug. Example of a CDF graph that is provided in bugs. CDF Squared Detection Technique The CDF squared technique detects changes in time-series histogram data by comparing CDFs between consecutive windows. It takes two CDFs, each representing the distribution of measurements over a time window, and computes the sum of squared differences between the two CDFs at each bin. The sign of the summed linear difference is then used to assign a direction to the squared difference score so that the output encodes whether the distribution moved to higher values (right shift) or lower values (left shift). For time-series detection, this base comparison is applied in a rolling fashion across the full history of data. Each day’s 7-day smoothed CDF is compared against the next one, producing a continuous signal of squared CDF differences over time. A Butterworth low-pass filter is then applied to that signal to remove high-frequency noise while preserving genuine trend changes. Finally, scipy’s find_peaks function is used to locate statistically significant peaks and valleys in the filtered signal using a dynamic alert threshold based on the historical data. Information is extracted from those areas and then used to build the detection information needed for the alert generation process. Alerting Our alerting tooling lives in the Treeherder codebase. It’s run through our PerfSheriff Bot (called Sherlock) and runs once per day. When a detection is produced from MozDetect, a telemetry alert is added to the database and then the TelemetryAlertManager is called to handle it. The manager’s tasks are split into 6 ordered phases: Update alerts with changes from Bugzilla. This step ensures that any changes that happen in the bugs filed are mirrored into our database. Currently, we only track resolution changes here. Comment on existing bugs. This step is for updating existing bugs with information from new alerts. This step is not currently being used. In the future, this could be used to inform probe owners that a probe which doesn’t produce bugs has produced an alert in the same time range. File new bugs for alerts. This step handles filing bugs for any new alerts on probes set up for producing bugs. Modify existing bugs with new alerts. This step handles any modifications needed to existing bugs based on the new bugs that were created. Currently, the “See Also” field is modified for existing bugs to include the new bugs. Produce emails for new alerts. This step handles producing emails for any alerts set up to produce emails. Housekeeping. This step handles redoing any failures that happen above in either the current run or past runs. Currently, it’s being used to retry bug modifications and sending emails when we encounter a failure there. This excludes retrying bug filling since we delete the alert in that case and retry it the next time the alert is generated. After the housekeeping step, the manager is done for the day and runs again on the next day to handle any updates and new alerts. Contrary to how alerting works for performance tests in CI, this process is fully automated and requires no human input at any point. Setting up telemetry probes for alerting happens on the mozilla-central side in their probe schema using the new monitor field in the metadata section (example for email alerts, example for bug alerts). The telemetry alerting documentation has information about how to do this. We then use an index.json file from the telemetry dictionary to gather all the probes that should be alerting. The information there is supplemented by more granular information later in the pipeline to gather things like the time unit used for the probe to be able to better format the Bugzilla bug table. Once a telemetry probe is set up for alerting and is found by our system, the owners (those listed in the email notification fields) will begin either receiving emails or have bugs produced for them. These can also be viewed by everyone on this dashboard. Example of an alert being viewed in the dashboard. Acknowledgements Getting the project to this point involved work from people across multiple teams here at Mozilla. Special thanks to Eduardo Filho for his support on the telemetry probe side, to Bas Schouten for his guidance and work on the CDF Squared detection technique, and to Andrej Glavic and Beatrice Acasandrei for their help in reviewing the Treeherder-related changes. If you hit any issues with the telemetry alerting system, or have any suggestions feel free to file a bug in the Testing :: Performance component or reach out to us in either #perf-help on Slack or in #perftest on Matrix.

Mozilla Data YouTube Channel: Towards a Telemetry Taxonomy

Thu, 23 Apr 2026 00:41:43 +0200

Leif Oines talks about an effort to define a more complete taxonomy for Mozilla's data.

Frederik Braun: Multiple things can be true at the same time

Thu, 23 Apr 2026 00:00:00 +0200

Dear reader. I am sure you have read a lot of blog posts about AI in the past weeks or months. And now I too am writing. Mostly to help me cope with what my kind of hacker people would call out as hypocrisy or cognitive dissonance. There are various …

Jonathan Almeida: Gmail filters based on X-Phabricator-Stamps header

Thu, 23 Apr 2026 02:00:00 +0200

I want Phabricator emails to have a Gmail label so I can know which patches had me as a reviewer that then had follow-up comments from other folks. This is useful for me when I review a patch and then I need to respond back to discussions in a more timely manner in comment threads that I've created. It's difficult to do this today similar to Bugzilla Gmail filters because there are fewer identifiers that the more simplistic Gmail filter parameters can help with. Today I learnt that there is an X-Phabricator-Stamps header in those Phabricator emails that let's you identify you as a the reviewer in a patch. So using that information, I wrote the Google script below to run every minute and avoid re-processing the same email twice. A couple variables were added to the top and some console.logs are sprinkled around for my own debugging. Code var REVIEWER = "jonalmeida"; var LABEL_NAME = "Phabricator/Comments"; var BODY_MATCH = "commented on this revision."; var SENDER = "phabricator@mozilla.com"; /** * Run once manually to install the per-minute trigger. */ function install() { uninstall(); ScriptApp.newTrigger('processInbox') .timeBased() .everyMinutes(1) .create(); } /** * Run once manually to remove the trigger. */ function uninstall() { ScriptApp.getProjectTriggers().forEach(function(t) { ScriptApp.deleteTrigger(t); }); PropertiesService.getScriptProperties().deleteProperty('lastRun'); } /** * Every run, we try to avoid processing the same email twice because * there is no API trigger to run a script on every new email received. */ function processInbox() { var props = PropertiesService.getScriptProperties(); var lastRun = parseInt(props.getProperty('lastRun') || '0'); var now = Math.floor(Date.now() / 1000); // On first run, look back 2 minutes if (lastRun === 0) { lastRun = now - 120; } var label = GmailApp.getUserLabelByName(LABEL_NAME); if (!label) { label = GmailApp.createLabel(LABEL_NAME); } console.log("last run: " + lastRun); var threads = GmailApp.search("from:" + SENDER + " after:" + lastRun); console.log("threads to process: " + threads.length); for (var i = 0; i < threads.length; i++) { var thread = threads[i]; var messages = thread.getMessages(); console.log("messages to process: " + messages.length); for (var j = 0; j < messages.length; j++) { if (hasReviewerStamp(messages[j])) { thread.addLabel(label); console.log(thread.getFirstMessageSubject()); break; } } } props.setProperty('lastRun', String(now)); } function hasReviewerStamp(message) { var raw = message.getRawContent(); var match = raw.match(/^X-Phabricator-Stamps:\s*(.+)$/m); if (!match) { return false; } var stamps = match[1].trim().split(/\s+/); return (stamps.indexOf("reviewer(@" + REVIEWER + ")") > -1) && raw.indexOf(BODY_MATCH) > -1; } /** * For debugging - see the list of labels you can search which * differs from what is used in the Gmail UI filter. */ function listAllLabels() { console.log("All labels"); var labels = GmailApp.getUserLabels(); for (var i = 0; i < labels.length; i++) { console.log(labels[i].getName()); } }

Mozilla Addons Blog: WebExtensions API Changes (Firefox 149-152)

Thu, 23 Apr 2026 23:30:12 +0200

Intro Hey everyone, we’ve been working on some exciting changes, and want to share them with you. But first, let me introduce myself. I am Christos, the new Sr. Developer Relations engineer in Add-ons, and I’m excited to write my first post on the Add-ons engineering blog. Deprecations and changes To start, I’m looking at a couple of features that are going away: avoiding content script execution in extension contexts, decoupling file access from host permissions, and improving the display of pageAction SVG icon. executeScript / registerContentScript in moz-extension documents Deprecated: Firefox 149 Removed: Firefox 152 Starting in Firefox Nightly 149 and scheduled for Firefox 152, the scripting and tabs injection APIs no longer inject into moz-extension://documents. This change brings the API in line with broader efforts to discourage string-based code execution in extension contexts, alongside the default CSP that restricts script-src to extension URLs and the removal of remote source allowlisting in MV3 (bug 1581608). Firefox emits a warning when this restriction is met, so you are aware of and can address any use of this process in your extensions. This is an example of the warning message: Content Script execution in moz-extension document has been deprecated and it has been blocked To work around this change, you can: Import scripts directly in the extension page’s HTML. Use module imports or standard tags in extension documents. Restructure code to avoid dynamic code execution patterns. An extension can run code in its documents dynamically by registering a runtime.onMessage listener in the document’s script, then sending a message to trigger execution of the required code. File access becomes opt-in Target: Firefox 152 Extensions requesting file://*/ or currently trigger the “Access your data for all websites” permission message, and when granted, can run content scripts in file:-URLs. From Firefox 152, file access in extensions requires an opt-in for all extensions, including those already installed (bug 2034168). pageAction SVG icon CSS filter (automatic color scheme) Removed: Firefox 152 Firefox has been automatically applying a greyscale and brightness CSS filter to pageAction (address bar button) SVG icons when a dark theme is active. This was intended to improve contrast, but it actually reduced contrast for multi-color icons and caused poor visibility for some extensions, such as Firefox Multi-Account Containers. For icons that adapt to light and dark color schemes, you can now use @media (prefers-color-scheme: dark) in the SVG icon, or the MV3 action manifest key, and specify theme_icons. Here is an example of how to use a `prefers-color-scheme` media query in a pageAction SVG icon to control how the icon adapts to dark mode: manifest.json "page_action": { "default_icon": "icons/icon.svg" } icons/icon.svg :root { color: black; } @media (prefers-color-scheme: dark) { :root { color: white; } } Use of prefers-color-scheme media queries is also allowed in MV2 browserAction and MV3 action SVG icons as an alternative to the theme_icons manifest properties. There are additional examples at the Mozilla Developer Network on how to test your extension pageAction icon with and without the implicit CSS filter. New APIs & Capabilities Now to the new stuff. Here, you get the ability to use popups without user activation, initial support for the new tab split view feature, and WebAuthn RP ID assertion. openPopup without user activation (Firefox Desktop) Available: Firefox 149 Desktop action.openPopup() and browserAction.openPopup() no longer require a user gesture on Firefox Desktop. You can open your extension’s popup programmatically, e.g., in response to a native-messaging event, an alarm, or a background-script condition. This change is part of the ongoing cross-browser alignment work in the WebExtensions Community Group to harmonize popup behavior across engines. Example Before (Firefox < 149): must hang off a user gesture, e.g., a context menu click: browser.menus.create({ id: "nudge", title: "Open popup", contexts: ["all"], }); browser.menus.onClicked.addListener((info) => { if (info.menuItemId === "nudge") { browser.action.openPopup(); // user clicked the menu → allowed } }); After (Firefox ≥ 149) — same intent, no user gesture needed, fires from a timer: browser.alarms.create("nudge", { delayInMinutes: 1 }); browser.alarms.onAlarm.addListener((alarm) => { if (alarm.name === "nudge") { browser.action.openPopup(); // works without a click } }); It’s the same call with the same result, but only the trigger changes from a user-action handler to any background event. It’s the same call with the same result, but only the trigger changes from a user-action handler to any background event. splitViewId in the tabs API Available: Firefox 149 Firefox 149 introduces a new read-only splitViewId property on the tabs.Tab object to expose Firefox’s new split view feature (where two tabs are displayed side-by-side in one window). Split views are treated as one unit, and Web Extensions treat them the same way. In Firefox 150, extensions can swap tabs within a split view. This update also resolves a confusing issue where using the user interface to reverse tab order incorrectly reports the tabs.onMoved event with inaccurate values. Additionally, Firefox introduces unsplitting behavior for web extensions: when tabs.move() is called with split-view tabs positioned separately (non-adjacently) in the array. Now, after the call, Firefox removes the split view rather than keeping the tabs locked together. Here is an example of using the new splitViewId property. // Log whenever a tab joins or leaves a split view. browser.tabs.onUpdated.addListener((tabId, changeInfo) => { if (!("splitViewId" in changeInfo)) return; if (changeInfo.splitViewId === browser.tabs.SPLIT_VIEW_ID_NONE) { console.log(`Tab ${tabId} left its split view`); } else { console.log(`Tab ${tabId} joined split view ${changeInfo.splitViewId}`); } }); // Firefox desktop also supports a filter to limite onUpdated events: // }, { properties: ["splitViewId"] }); Firefox 151 enables extensions to move split views in tab groups. More improvements are coming, such as the ability to create split views from extensions (bug 2016928). WebAuthn RP ID assertion Available: Firefox 150 Previously, web extensions couldn’t use WebAuthn credentials registered on their company’s website or mobile apps. When extensions tried to set a custom Relying Party ID (RP ID) in navigator.credentials.create() or navigator.credentials.get(), Firefox rejected it with “SecurityError: The operation is insecure.” With Firefox 150, Extensions can now assert a WebAuthn RP ID for any domain they have host permissions for when calling navigator.credentials.create() or navigator.credentials.get(). This applies to both the publicKey.rp.id field during credential creation and the publicKey.rpId field during authentication. A critical detail for server-side validation: When relying party servers validate credentials created by extensions, they must account for different origin formats across browsers. In Chrome, the origin follows the pattern chrome-extension://extensionid, which matches the extension’s location.origin. Firefox 150 introduces a new stable origin format: moz-extension://hash, where the hash is a 64-character SHA-256 representation of the extension ID (using characters a-p to represent hex values). Importantly, this hash-based origin is the same all users, unlike Firefox’s existing UUID-based moz-extension:// URLs used for extension documents. To extract the origin from a credential for validation: let clientData = JSON.parse(new TextDecoder().decode( publicKeyCredential.response.clientDataJSON )); console.log(clientData.origin); For more details, see Use Web Authn API in web extensions on MDN. Summary Change Type Firefox Version executeScript / registerContentScript in moz-extension documents Deprecation → Removal Deprecated 149, removed 152 File access opt-in Change 152 pageAction SVG CSS filter Removal 152 openPopup() without user activation New capability 149 (Desktop only) splitViewId on tabs.Tab New API 149 WebAuthn RP ID assertion New capability 150 Need more? You can always find detailed information about WebExtensions API and Add-ons updates in the MDN release notes, e.g., for Firefox 149 and Firefox 150. For any help or questions navigating any changes, don’t hesitate to post your topic on the Add-ons Discourse. The post WebExtensions API Changes (Firefox 149-152) appeared first on Mozilla Add-ons Community Blog.

Wil Clouser: Firefox Sync adds official PostgreSQL support

Thu, 23 Apr 2026 09:00:00 +0200

The Sync Storage team has landed official PostgreSQL support for Firefox Sync. Historically, Sync has only officially supported Google Spanner as a storage backend, with MySQL working unofficially. That has been a pretty high barrier to entry for people self-hosting their own services. With PostgreSQL support, we hope to make self-hosting more approachable and continue supporting people who want the agency of hosting their data on infrastructure they control. There is updated documentation for running it with Docker, including a one-shot docker compose setup: https://mozilla-services.github.io/syncstorage-rs/how-to/how-to-run-with-docker.html Mozilla is publishing Docker images for the PostgreSQL build here: https://ghcr.io/mozilla-services/syncstorage-rs/syncstorage-rs-postgres If you’ve been interested in self-hosting Sync but were put off by the storage requirements, take another look. If you run into bugs or have feedback, please file issues here: https://github.com/mozilla-services/syncstorage-rs/issues

Jonathan Almeida: Rebase all WIPs to the latest upstream head

Tue, 28 Apr 2026 20:00:00 +0200

A small pet-peeve with fetching the latest main on jujutsu is that I like to move all my WIP patches to the new one. That's also nice because jj doesn't make me fix the conflicts immediately! The solution from a co-worker (kudos to skippyhammond!) is to query all immediate decendants of the previous main after the fetch. jj git fetch # assuming 'z' is the rev-id of the previous main. jj rebase -s "mutable()&z+" -d main I haven't learnt how to make aliases accept params with it yet, so this will have to do for now. Update: After a bit of searching, it seems that today this is only possible by wrapping it in a shell script. Based on the examples in the jj documentation an alias would look like this: Update 2: After some months of usage across multiple repositories, I've found it better to be clear with the destination since main, trunk or others can be tracked with a combination of repository aliases too. [aliases] # Update all revs to the latest main; point to the previous one. hoist = ["util", "exec", "--", "bash", "-c", """ set -euo pipefail jj rebase -s "mutable()&$1+" -d "$2" """, ""] You can use this to rebase all your WIPs like so: $ jj hoist If my previous main revision was kz, this is what I would end up doing: $ jj fetch origin $ jj hoist kz main@origin

Jonathan Almeida: My Firefox for Android local build environment

Fri, 24 Apr 2026 20:00:00 +0200

The Firefox for Android app has always had a complicated build process - we're cramping a complex cross-platform browser engine and all the related components that make it work on Android into one package. In its current form, it lives in the Firefox mono-repo at mozilla-central (now mozilla-firefox using the git repository). I wanted to document my "artifact-mode" environment here since it's worked quite successfully for me for many years with minor changes. NOTE: After a fresh clone of the mono-repo, don't forget to first run and follow the prompts of ./mach bootstrap . mozconfig My mozconfig below is enabled for artifact mode, but occasionally I switch between various configurations. You can see those commented out, with these few extra notes: I like to separate out my objdirs to avoid cache pollution between the different build types. I think you can get away without needing to specify this and an objdir for your build type and arch will be generated. sccache speeds up the native portion of full builds after the first slow one, but it's a hit or miss if you fetch from the remote repository but don't need to rebuild as often. I don't care to manually run the clobber step, and I don't truly appreciate why that isn't always automatically done. Emilio's mozconfig manager looks like a better solution, however my needs are very simple. # Build GeckoView/Firefox for Android: ac_add_options --enable-application=mobile/android # Targeting the following architecture. # For regular phones, no --target is needed. # For x86 emulators (and x86 devices, which are uncommon): # ac_add_options --target=i686 # For newer phones or Apple silicon ac_add_options --target=aarch64 # For x86_64 emulators (and x86_64 devices, which are even less common): # ac_add_options --target=x86_64 # sccache will significantly speed up your builds by caching # compilation results. The Firefox build system will download # sccache automatically. # This only works for non-artifact builds. #ac_add_options --with-ccache=sccache # Enable artifact builds; manager-mode. ac_add_options --enable-artifact-builds # Write build artifacts to.. ## Full build dir #mk_add_options MOZ_OBJDIR=./objdir-droid #mk_add_options MOZ_OBJDIR=./objdir-desktop ## Artifact builds mk_add_options MOZ_OBJDIR=./objdir-frontend # Automatic clobbering; don't ask me. mk_add_options AUTOCLOBBER=1 JAVA_HOME Sometimes you might find yourself needing to run a (non-mach) command in the terminal. Those typically will need to invoke some parts of gradle for an Android build, so it's best to make sure those are using the same JDK as the bootstrapped one in the mono-repo. This avoids weird build errors where something that compiles in one place isn't working in another (like Android Studio). The location for the JDKs are typically in ~/.mozbuild/jdk/, and if you've between around for ~6 months you end up with multiple versions after every JDK bump: $ ls -l ~/.mozbuild/jdk/ drwxr-xr-x@ - jalmeida 15 Apr 2025 jdk-17.0.15+6 drwxr-xr-x@ - jalmeida 15 Jul 2025 jdk-17.0.16+8 drwxr-xr-x@ - jalmeida 21 Oct 2025 jdk-17.0.17+10 drwxr-xr-x@ - jalmeida 20 Jan 09:00 jdk-17.0.18+8 drwxr-xr-x@ - jalmeida 26 Feb 15:04 mozboot You can find some way to point your latest JDK to one location or you can be lazy like me and pick the latest version to assign as your JAVA_HOME property by adding this to your shell's RC file: export JAVA_HOME="$(ls -1dr -- $HOME/.mozbuild/jdk/jdk-* | head -n 1)/Contents/Home" Android Studio Similarly for Android Studio, let's do the same so that environment is identical. Head to, Settings | Build, Execution, Deployment | Build Tools | Gradle, and ensure that "Gradle JDK" path is set to JAVA_HOME. Lately, the default seems to be for it to follow GRADLE_LOCAL_JAVA_HOME which is a property we can't easily override, so we have to manually set this ourselves. Using the same Android SDK also helps speed things up and avoids source confusion. You can typically find it in ~/.mozbuild/android-sdk-macosx and update it at Settings | Languages & Frameworks | Android SDK. Debugging This section is for miscellaneous build error situations that come-up, but assuming mach build work and there are no known Android build changes, my solution has typically always been the same. For example, the other day I fetched another engineers patch to test out locally1 as part of reviewing it where I faced the error message below: Execution failed for task ':components:feature-pwa:compileDebugKotlin'. FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':components:feature-pwa:compileDebugKotlin'. > A failure occurred while executing org.jetbrains.kotlin.compilerRunner.GradleCompilerRunnerWithWorkers$GradleKotlinCompilerWorkAction > Internal compiler error. See log for more details * Try: > Run with --info or --debug option to get more log output. > Run with --scan to generate a Build Scan (powered by Develocity). > Get more help at https://help.gradle.org. * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':components:feature-pwa:compileDebugKotlin'. at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.lambda$executeIfValid$1(ExecuteActionsTaskExecuter.java:135) at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:288) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:133) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:121) at org.gradle.api.internal.tasks.execution.ProblemsTaskPathTrackingTaskExecuter.execute(ProblemsTaskPathTrackingTaskExecuter.java:41) at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46) at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:51) at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57) at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:74) at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36) at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77) at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55) at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:209) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:166) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53) at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52) at org.gradle.execution.plan.DefaultNodeExecutor.executeLocalTaskNode(DefaultNodeExecutor.java:55) at org.gradle.execution.plan.DefaultNodeExecutor.execute(DefaultNodeExecutor.java:34) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:355) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:343) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.lambda$execute$0(DefaultTaskExecutionGraph.java:339) at org.gradle.internal.operations.CurrentBuildOperationRef.with(CurrentBuildOperationRef.java:84) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:339) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:328) at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:459) at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:376) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) at org.gradle.internal.concurrent.AbstractManagedExecutor$1.run(AbstractManagedExecutor.java:47) Caused by: org.gradle.workers.internal.DefaultWorkerExecutor$WorkExecutionException: A failure occurred while executing org.jetbrains.kotlin.compilerRunner.GradleCompilerRunnerWithWorkers$GradleKotlinCompilerWorkAction at org.gradle.workers.internal.DefaultWorkerExecutor$WorkItemExecution.waitForCompletion(DefaultWorkerExecutor.java:289) at org.gradle.internal.work.DefaultAsyncWorkTracker.lambda$waitForItemsAndGatherFailures$2(DefaultAsyncWorkTracker.java:130) at org.gradle.internal.Factories$1.create(Factories.java:33) at org.gradle.internal.work.DefaultWorkerLeaseService.lambda$withoutLocks$2(DefaultWorkerLeaseService.java:344) at org.gradle.internal.work.ResourceLockStatistics$1.measure(ResourceLockStatistics.java:42) at org.gradle.internal.work.DefaultWorkerLeaseService.withoutLocks(DefaultWorkerLeaseService.java:342) at org.gradle.internal.work.DefaultWorkerLeaseService.withoutLocks(DefaultWorkerLeaseService.java:326) at org.gradle.internal.work.DefaultWorkerLeaseService.withoutLock(DefaultWorkerLeaseService.java:331) at org.gradle.internal.work.DefaultAsyncWorkTracker.waitForItemsAndGatherFailures(DefaultAsyncWorkTracker.java:126) at org.gradle.internal.work.DefaultAsyncWorkTracker.waitForItemsAndGatherFailures(DefaultAsyncWorkTracker.java:92) at org.gradle.internal.work.DefaultAsyncWorkTracker.waitForAll(DefaultAsyncWorkTracker.java:78) at org.gradle.internal.work.DefaultAsyncWorkTracker.waitForCompletion(DefaultAsyncWorkTracker.java:66) at org.gradle.api.internal.tasks.execution.TaskExecution$3.run(TaskExecution.java:260) at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29) at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:166) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:47) at org.gradle.api.internal.tasks.execution.TaskExecution.executeAction(TaskExecution.java:237) at org.gradle.api.internal.tasks.execution.TaskExecution.executeActions(TaskExecution.java:220) at org.gradle.api.internal.tasks.execution.TaskExecution.executeWithPreviousOutputFiles(TaskExecution.java:203) at org.gradle.api.internal.tasks.execution.TaskExecution.execute(TaskExecution.java:170) at org.gradle.internal.execution.steps.ExecuteStep.executeInternal(ExecuteStep.java:105) at org.gradle.internal.execution.steps.ExecuteStep.access$000(ExecuteStep.java:44) at org.gradle.internal.execution.steps.ExecuteStep$1.call(ExecuteStep.java:59) at org.gradle.internal.execution.steps.ExecuteStep$1.call(ExecuteStep.java:56) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:209) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:166) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53) at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:56) at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:44) at org.gradle.internal.execution.steps.CancelExecutionStep.execute(CancelExecutionStep.java:42) at org.gradle.internal.execution.steps.TimeoutStep.executeWithoutTimeout(TimeoutStep.java:75) at org.gradle.internal.execution.steps.TimeoutStep.execute(TimeoutStep.java:55) at org.gradle.internal.execution.steps.PreCreateOutputParentsStep.execute(PreCreateOutputParentsStep.java:50) at org.gradle.internal.execution.steps.PreCreateOutputParentsStep.execute(PreCreateOutputParentsStep.java:28) at org.gradle.internal.execution.steps.RemovePreviousOutputsStep.execute(RemovePreviousOutputsStep.java:68) at org.gradle.internal.execution.steps.RemovePreviousOutputsStep.execute(RemovePreviousOutputsStep.java:38) at org.gradle.internal.execution.steps.BroadcastChangingOutputsStep.execute(BroadcastChangingOutputsStep.java:61) at org.gradle.internal.execution.steps.BroadcastChangingOutputsStep.execute(BroadcastChangingOutputsStep.java:26) at org.gradle.internal.execution.steps.CaptureOutputsAfterExecutionStep.execute(CaptureOutputsAfterExecutionStep.java:69) at org.gradle.internal.execution.steps.CaptureOutputsAfterExecutionStep.execute(CaptureOutputsAfterExecutionStep.java:46) at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:39) at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:28) at org.gradle.internal.execution.steps.BuildCacheStep.executeWithoutCache(BuildCacheStep.java:189) at org.gradle.internal.execution.steps.BuildCacheStep.lambda$execute$1(BuildCacheStep.java:75) at org.gradle.internal.Either$Right.fold(Either.java:176) at org.gradle.internal.execution.caching.CachingState.fold(CachingState.java:62) at org.gradle.internal.execution.steps.BuildCacheStep.execute(BuildCacheStep.java:73) at org.gradle.internal.execution.steps.BuildCacheStep.execute(BuildCacheStep.java:48) at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:46) at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:35) at org.gradle.internal.execution.steps.SkipUpToDateStep.executeBecause(SkipUpToDateStep.java:75) at org.gradle.internal.execution.steps.SkipUpToDateStep.lambda$execute$2(SkipUpToDateStep.java:53) at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:53) at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:35) at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:37) at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:27) at org.gradle.internal.execution.steps.ResolveIncrementalCachingStateStep.executeDelegate(ResolveIncrementalCachingStateStep.java:49) at org.gradle.internal.execution.steps.ResolveIncrementalCachingStateStep.executeDelegate(ResolveIncrementalCachingStateStep.java:27) at org.gradle.internal.execution.steps.AbstractResolveCachingStateStep.execute(AbstractResolveCachingStateStep.java:71) at org.gradle.internal.execution.steps.AbstractResolveCachingStateStep.execute(AbstractResolveCachingStateStep.java:39) at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:64) at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:35) at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:62) at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:40) at org.gradle.internal.execution.steps.AbstractCaptureStateBeforeExecutionStep.execute(AbstractCaptureStateBeforeExecutionStep.java:76) at org.gradle.internal.execution.steps.AbstractCaptureStateBeforeExecutionStep.execute(AbstractCaptureStateBeforeExecutionStep.java:45) at org.gradle.internal.execution.steps.AbstractSkipEmptyWorkStep.executeWithNonEmptySources(AbstractSkipEmptyWorkStep.java:136) at org.gradle.internal.execution.steps.AbstractSkipEmptyWorkStep.execute(AbstractSkipEmptyWorkStep.java:66) at org.gradle.internal.execution.steps.AbstractSkipEmptyWorkStep.execute(AbstractSkipEmptyWorkStep.java:38) at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsStartedStep.execute(MarkSnapshottingInputsStartedStep.java:38) at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:36) at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:23) at org.gradle.internal.execution.steps.HandleStaleOutputsStep.execute(HandleStaleOutputsStep.java:75) at org.gradle.internal.execution.steps.HandleStaleOutputsStep.execute(HandleStaleOutputsStep.java:41) at org.gradle.internal.execution.steps.AssignMutableWorkspaceStep.lambda$execute$0(AssignMutableWorkspaceStep.java:35) at org.gradle.api.internal.tasks.execution.TaskExecution$4.withWorkspace(TaskExecution.java:297) at org.gradle.internal.execution.steps.AssignMutableWorkspaceStep.execute(AssignMutableWorkspaceStep.java:31) at org.gradle.internal.execution.steps.AssignMutableWorkspaceStep.execute(AssignMutableWorkspaceStep.java:22) at org.gradle.internal.execution.steps.ChoosePipelineStep.execute(ChoosePipelineStep.java:40) at org.gradle.internal.execution.steps.ChoosePipelineStep.execute(ChoosePipelineStep.java:23) at org.gradle.internal.execution.steps.ExecuteWorkBuildOperationFiringStep.lambda$execute$2(ExecuteWorkBuildOperationFiringStep.java:67) at org.gradle.internal.execution.steps.ExecuteWorkBuildOperationFiringStep.execute(ExecuteWorkBuildOperationFiringStep.java:67) at org.gradle.internal.execution.steps.ExecuteWorkBuildOperationFiringStep.execute(ExecuteWorkBuildOperationFiringStep.java:39) at org.gradle.internal.execution.steps.IdentityCacheStep.execute(IdentityCacheStep.java:46) at org.gradle.internal.execution.steps.IdentityCacheStep.execute(IdentityCacheStep.java:34) at org.gradle.internal.execution.steps.IdentifyStep.execute(IdentifyStep.java:44) at org.gradle.internal.execution.steps.IdentifyStep.execute(IdentifyStep.java:31) at org.gradle.internal.execution.impl.DefaultExecutionEngine$1.execute(DefaultExecutionEngine.java:64) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:132) ... 30 more Caused by: org.jetbrains.kotlin.gradle.tasks.FailedCompilationException: Internal compiler error. See log for more details at org.jetbrains.kotlin.gradle.tasks.TasksUtilsKt.throwExceptionIfCompilationFailed(tasksUtils.kt:22) at org.jetbrains.kotlin.compilerRunner.GradleKotlinCompilerWork.run(GradleKotlinCompilerWork.kt:112) at org.jetbrains.kotlin.compilerRunner.GradleCompilerRunnerWithWorkers$GradleKotlinCompilerWorkAction.execute(GradleCompilerRunnerWithWorkers.kt:75) at org.gradle.workers.internal.DefaultWorkerServer.execute(DefaultWorkerServer.java:68) at org.gradle.workers.internal.NoIsolationWorkerFactory$1$1.create(NoIsolationWorkerFactory.java:64) at org.gradle.workers.internal.NoIsolationWorkerFactory$1$1.create(NoIsolationWorkerFactory.java:61) at org.gradle.internal.classloader.ClassLoaderUtils.executeInClassloader(ClassLoaderUtils.java:100) at org.gradle.workers.internal.NoIsolationWorkerFactory$1.lambda$execute$0(NoIsolationWorkerFactory.java:61) at org.gradle.workers.internal.AbstractWorker$1.call(AbstractWorker.java:44) at org.gradle.workers.internal.AbstractWorker$1.call(AbstractWorker.java:41) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:209) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:166) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53) at org.gradle.workers.internal.AbstractWorker.executeWrappedInBuildOperation(AbstractWorker.java:41) at org.gradle.workers.internal.NoIsolationWorkerFactory$1.execute(NoIsolationWorkerFactory.java:58) at org.gradle.workers.internal.DefaultWorkerExecutor.lambda$submitWork$0(DefaultWorkerExecutor.java:176) at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner.runExecution(DefaultConditionalExecutionQueue.java:194) at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner.access$700(DefaultConditionalExecutionQueue.java:127) at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner$1.run(DefaultConditionalExecutionQueue.java:169) at org.gradle.internal.Factories$1.create(Factories.java:33) at org.gradle.internal.work.DefaultWorkerLeaseService.lambda$withLocksAcquired$0(DefaultWorkerLeaseService.java:269) at org.gradle.internal.work.ResourceLockStatistics$1.measure(ResourceLockStatistics.java:42) at org.gradle.internal.work.DefaultWorkerLeaseService.withLocksAcquired(DefaultWorkerLeaseService.java:267) at org.gradle.internal.work.DefaultWorkerLeaseService.withLocks(DefaultWorkerLeaseService.java:259) at org.gradle.internal.work.DefaultWorkerLeaseService.runAsWorkerThread(DefaultWorkerLeaseService.java:127) at org.gradle.internal.work.DefaultWorkerLeaseService.runAsWorkerThread(DefaultWorkerLeaseService.java:132) at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner.runBatch(DefaultConditionalExecutionQueue.java:164) at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner.run(DefaultConditionalExecutionQueue.java:133) ... 2 more The full trace was long and didn't seem related to a code failure in the module itself. So I employed the solution, which is always the same: ./mach build In Android Studio, File > Sync Project with Gradle Files. Yup, that's all. Very simple and boring. 1 With Jujutsu, this is the moz-phab command I use which has made it easier to manage review patches: moz-phab patch --no-branch --apply-to main@origin Comments With an account on the Fediverse or Mastodon, you can respond to this post. Since Mastodon is decentralized, you can use your existing account hosted by another Mastodon server or compatible platform if you don't have an account on this one. Known non-private replies are displayed below. Learn how this was implemented from the original source here. Load comments Loading comments relies on JavaScript. Try enabling JavaScript and reloading, or visit the original post on Mastodon. You need JavaScript to view the comments. &>"'

Mozilla Data YouTube Channel: Glean Dictionary Looker Demo

Tue, 28 Apr 2026 23:37:03 +0200

A quick demonstration of the Glean Dictionary's new integration with Mozilla's instance of Looker.

Firefox Tooling Announcements: MozPhab 2.13.1 Released

Tue, 28 Apr 2026 21:40:19 +0200

Bugs resolved in Moz-Phab 2.13.1: bug 2033054 Add AGENTS.md/CLAUDE.md for moz-phab bug 2034269 reorg --force aborts on abandoned-revision ghost links in stackGraph Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix. 1 post - 1 participant Read full topic

This Week In Rust: This Week in Rust 649

Wed, 29 Apr 2026 06:00:00 +0200

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions. This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR. Want TWIR in your inbox? Subscribe here. Updates from Rust Community Newsletters The Embedded Rustacean Issue #70 Scientific Computing in Rust #17 (April 2026) Project/Tooling Updates lean-ctx: A Context Runtime for AI Coding Agents Zed is 1.0 Niri v26.04 Announcing Symposium menhera-cooldown: The crates.io Cooldown Proxy cargo-cooldown 0.3.0: a Cargo wrapper for supply-chain cooldowns Nutype 0.7.0 AimDB: Reactive Pipelines as the Engine of the Data-First Architecture pyscan v2.1.0: Python Dependency Vulnerability Scanner flodl 0.5.3 Blade XR Asteroids Observations/Thoughts Bugs Rust Won't Catch A Gopher Meets a Crab Using Rust to Build a $1 Handheld Gaming Console All databases will eventually be (re)written in Rust [video] Rust India Conference 2026 — Full Talk Recordings [audio] Helsing with Jon Gjengset Rust Walkthroughs Build a JSON Parser in Rust from Scratch device-envoy-esp: Making Embedded ESP32 Fun: With Rust, Embassy, and Composable Device Abstractions Rust Projects - Write a Redis Clone - Version 2.0.0 [video] Rust Parallelism with Rayon - Use ALL CPUs Research Performance of Rust language Miscellaneous awesome axum Crate of the Week This week's crate is dithr, a buffer-first dithering and halftoning library. Thanks to pbkx for the self-suggestion! Please submit your suggestions and votes for next week! Calls for Testing An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization. If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing. No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs. Let us know if you would like your feature to be tracked as a part of this list. Call for Participation; projects and speakers CFP - Projects Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started! Some of these tasks may also have mentors available, visit the task page for more information. If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon! CFP - Events Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker. EuroRust 2026| 2026-05-04 (extended) | Barcelona, Spain | 2026-10-14 – 2026-10-17 NDC Techtown | 2026-05-03 | Kongsberg, Norway | 2026-09-21 to 23. Scientific Computing in Rust 2026| 2026-06-05 | Virtual | 2026-07-08 - 2026-07-10 If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon! Updates from the Rust Project 480 pull requests were merged in the last week Compiler AliasTerm refactor add on_unmatch_args diagnostic attribute eliminate CrateMetadataRef fix performance regression introduced in #142531 by excluding Storage{Live,Dead} from CGU size estimation prefer -1 for None prevent deref coercions in pin! streamline CrateMetadataRef construction in provide_one! Library constify Vec comparisons exposing Float Masks fix heap overflow in slice::join caused by misbehaving Borrow generalize IO Traits for Arc where &T: IoTrait maintain CStringArray null-termination even if Vec::push panics move std::io::RawOsError to core::io implement more traits for field-representing types Cargo clean: do not error if explicitly specified target-dir does not exist compile: stabilize build.warnings compile: ignore unused deps if also transitive compile: Log all ignored unused externs Clippy manual_assert_eq: new lint new module style lint: inline_modules needless_ifs: handle vertical tab as whitespace to avoid false negative inline_modules: fix the rust version the lint was introduced in make unused_format_specs catch width issues fix from_over_into false positive with conflicting blanket From impl fix wrong question_mark suggestion when match arm body is a destructuring assignment Rust-Analyzer add .new postfix completion based on expected type (rust-lang/r… add unwrap_block, offer unwrap_block and unwrap_branch handle if matches!() for replace_if_let_with_match offer on compound assign for replace_arith_op offer on non-block matcharm for unwrap_branch when renaming a field, rename variables in constructors as well fix trait auto import appearing again when trait already been imported as _ avoid prelude paths when imports.preferPrelude is false define the ABI of functions inside extern blocks as the ABI of the extern block fix closure capture hints being misplaced for async closures generate-method skips trait impl blocks when picking insertion site keep the same nonce when cloning a RootDatabase make InferenceResult::binding_mode() fallible mark enum variants as deprecated when their parent enum is deprecated no complete where kw after qualified path offer on ! for apply_demorgan_iterator offer on is_some_and etc. for apply_demorgan_iterator parse return #[attr] expr parse impl restrictions after the visibility pass proc_macro_cwd to Analysis::from_single_file() suppress infer vars in monomorphization migrate replace qualified name with use to SyntaxEditor perf: optimize allocation strategies of output/parser/event remove generate impl non syntax factory variant Rust Compiler Performance Triage Relatively few perf-affecting changes this week. Perf report is more positive than users should see due to the -Zincremental-verify-ich related improvements in #155473. Triage done by @simulacrum. Revision range: 9ab01ae5..ca9a134e 1 Regression, 5 Improvements, 3 Mixed; 3 of them in rollups 32 artifact comparisons made in total Full report here Approved RFCs Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: No RFCs were approved this week. Final Comment Period Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. Tracking Issues & PRs Rust Consider Result and ControlFlow to be equivalent to T for must use lint Switch the destructors implementation for thread locals on Windows to use FLS Stabilize VecDeque::truncate_front Derives Copy for ffi::FromBytesUntilNulError Tracking Issue for ExitCodeExt on Windows remove forever-deprecated and hidden f64 methods Cargo Remove curl dependency from crates-io crate Compiler Team (MCPs only) Make stable hashing names consistent replace box_patterns in the compiler with deref_patterns Create a new Tier 3 target: powerpc64le-unknown-none Rust RFCs RFC: Inheriting of default-features in Cargo Rust Foundation Maintainer Fund build-std: explicit dependencies Unsafe Code Guidelines Should validity of a reference depend on the contents of memory in any way? No Items entered Final Comment Period this week for Language Reference, Language Team or Leadership Council. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list. New and Updated RFCs Bounded Trait Casting Named Fn trait parameters Upcoming Events Rusty Events between 2026-04-29 - 2026-05-27 🦀 Virtual 2026-04-29 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-05-01 | Virtual (Nürnberg, DE) | Rust Nuremberg Hacker's Hike 0x1 2026-05-02 | Virtual (Kampala, UG) | Rust Circle Meetup Rust Circle Meetup 2026-05-03 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Rust Deep Learning: First Sunday 2026-05-05 | Virtual (Tel Aviv-yafo, IL) | Code Mavens 🦀 - 🐍 - 🐪 Rust code reading and open source contribution 2026-05-06 | Virtual (Cardiff, UK) | Rust and C++ Cardiff Practical introduction to SIMD 2026-05-06 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-05-06 | Virtual (Indianapolis, IN, US) | Indy Rust Indy.rs - with Social Distancing 2026-05-07 | Virtual (Berlin, DE) | Rust Berlin Rust Hack and Learn 2026-05-07 | Virtual (Nürnberg, DE) | Rust Nuremberg Rust Nürnberg online 2026-05-12 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Second Tuesday 2026-05-12 | Virtual (London, UK) | Women in Rust 👋 Community Catch Up 2026-05-17 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Rust Deep Learning: Third Sunday 2026-05-19 | Virtual (Washington, DC, US) | Rust DC Mid-month Rustful 2026-05-20 | Hybrid (Vancouver, BC, CA) | Vancouver Rust Mouse Control with Rust 2026-05-20 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-05-21 | Hybrid (Seattle, WA, US) | Seattle Rust User Group May, 2026 SRUG (Seattle Rust User Group) Meetup 2026-05-21 | Virtual (Berlin, DE) | Rust Berlin Rust Hack and Learn 2026-05-21 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup Tock OS Part #4 - Capsule coding in QEMU! 2026-05-26 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Fourth Tuesday 2026-05-26 | Virtual (London, UK) | Women in Rust Lunch & Learn: Seeing Into Your Code - A Practical Guide to Tracing in Rust 2026-05-27 | Virtual (Girona, ES) | Rust Girona Weekly coding session Asia 2026-05-13 | Malaysia, MY | Rust Meetup Malaysia Rust Meetup May 2026 2026-05-16 | Bangalore, IN | Rust Bangalore May 2026 Rustacean meetup Europe 2026-04-29 | Copenhagen, DK | Copenhagen Rust Community Rust meetup #67 2026-04-29 | Paris, FR | Paris Rustaceans Rust Meetup in Paris 2026-04-30 | Berlin, DE | Rust Berlin Rust Berlin Talks: The next generation 2026-04-30 | Manchester, GB | Rust Manchester Rust Manchester April Talk 2026-05-02 | Augsburg, DE | Rust Munich and Rust Augsburg Augsburger Linux-Infotag 2026: Gemeinschaftsstand Rust Augsburg und Rust München 2026-05-04 | Amsterdam, NH, NL | Rust Developers Amsterdam Group Rust Meetup @ JetBrains 2026-05-04 | Frankfurt, DE | Rust Rhein-Main Writing a stock portfolio simulation in Rust with Leptos 2026-05-05 | Olomouc, CZ | Rust Moravia 5. Rust Moravia Meetup (Ukaž testy!) 2026-05-06 | Milano, MI, IT | Rust Language Milan Rust Milan @ Python Milano: Python or Rust? Yes! 2026-05-06 | Oxford, UK | Oxford ACCU/Rust Meetup. Building LLMs from scratch 2026-05-07 | Edinburgh, UK | Rust and Friends Rust May Talks: Aetherus + Bevy 2026-05-13 | Girona, ES | Rust Girona Rust Girona Hack & Learn 05 2026 2026-05-14 | Switzerland, CH | PostTenebrasLab Rust Meetup Geneva 2026-05-18 - 2026-05-23 | Amsterdam, NL | RustWeek 2026 RustWeek 2026 2026-05-19 | Aarhus, DK | Rust Aarhus Hack Night 2026-05-19 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig Cross-Building & Cross-Testing 2026-05-19 | London, UK | Women in Rust RustWeek lunch meetup 2026-05-21 | Amsterdam, NL | RustNL RustWeek Hackathon 2026-05-22 | Amsterdam, NL | RustNL Bike tour around Utrecht 2026-05-26 | Dortmund, DE | Rust Dortmund Rust Dortmund Meetup - Agentic Programming - May 2026-05-26 | Manchester, UK | Rust Manchester Rust Manchester May Code Night North America 2026-04-30 | Atlanta, GA, US | Rust Atlanta Rust-Atl 2026-04-30 | Mountain View, CA, US | Hacker Dojo RUST MEETUP at HACKER DOJO 2026-05-02 | Boston, MA, US | Boston Rust Meetup Alewife Rust Lunch, May 2 2026-05-07 | Saint Louis, MO, US | STL Rust Open Project Night 2026-05-09 | Boston, MA, US | Boston Rust Meetup Back Bay Rust Lunch, May 9 2026-05-14 | Portland, OR, US | PDXRust From Radio Waves to Pixels - Real-Time Visualizations with Rust and WebAssembly 2026-05-14 | San Diego, CA, US | San Diego Rust San Diego Rust May Meetup - Back in person! 2026-05-16 | Boston, MA, US | Boston Rust Meetup Lechmere Rust Lunch, May 16 2026-05-19 | San Francisco, CA, US | San Francisco Rust Study Group Rust Hacking in Person 2026-05-20 | Hybrid (Vancouver, BC, CA) | Vancouver Rust Mouse Control with Rust 2026-05-20 | San Francisco, CA, US | Bay Area Rust Meetup Bay Area Rust Meetup 2026-05-21 | Hybrid (Seattle, WA, US) | Seattle Rust User Group May, 2026 SRUG (Seattle Rust User Group) Meetup 2026-05-21 | Nashville, TN, US | Music City Rust Developers Community Meetup 2026-05-23 | Boston, MA, US | Boston Rust Meetup Allston Rust Lunch, May 23 2026-05-27 | Austin, TX, US | Rust ATX Rust Lunch - Fareground Oceania 2026-05-14 | Melbourne, AU | Rust Melbourne Rust Melbourne - May 2026 2026-05-26 | Barton, ACT, AU | Canberra Rust User Group May Meetup South America 2026-05-13 | Montevideo, UY | Rust Meetup Uruguay Rust Uruguay meetup de Mayo If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access. Jobs Please see the latest Who's Hiring thread on r/rust Quote of the Week Sometimes, the best projects are the ones you never thought you could build. – Chris Dell on his blog Another week bereft of any quote suggestions. llogiq is glad to have found this anyway. Please submit quotes and vote for next week! This Week in Rust is edited by: nellshamrell llogiq ericseppanen extrawurst U007D mariannegoldin bdillo opeolluwa bnchi KannanPalani57 tzilist Email list hosting is sponsored by The Rust Foundation Discuss on r/rust

Firefox Tooling Announcements: MozPhab 2.14.0 Released

Wed, 29 Apr 2026 06:15:13 +0200

Bugs resolved in Moz-Phab 2.14.0: bug 2032102 Parallelize revision creation and diff property calls in submit for faster stack submission Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix. 1 post - 1 participant Read full topic

The Servo Blog: March in Servo: keyboard navigation, better debugging, FreeBSD support, and more!

Thu, 30 Apr 2026 02:00:00 +0200

Servo 0.1.0 represents Servo’s biggest month ever, with a record 530 commits and our first ever release on crates.io! For security fixes, see § Security. With this release Servo becomes more accessible, thanks to tab navigation (@mrobinson, @Loirooriol, #42952, #43019, #43058, #43246, #43267, #43067), keyboard navigation with Alt+Shift and the accesskey attribute (@mrobinson, #43031, #43144, #43434), and keyboard scrolling with Space and Shift+Space (@mrobinson, #43322). We’ve shipped several new web platform features: (@BudiArb, @rayguo17, @mrobinson, #41562) (@TimvdLippe, #43150) and (@Loirooriol, #43583) ‘X-Frame-Options’ (@TimvdLippe, #43539, #43708) ‘Content-Security-Policy: frame-ancestors’ (@TimvdLippe, #43630) ‘::first-letter’ styling (@minghuaw, @xiaochengh, @Loirooriol, #43027) ‘::placeholder’ styling (@stevennovaryo, #43053) ‘::file-selector-button’ styling (@lukewarlow, @AlexVasiluta, #43498) ‘background-blend-mode’ (@mrobinson, #43666) ‘content’ on ‘::marker’ (@niyabits, @Loirooriol, #43515) ‘list-style-type: ’ (@Loirooriol, #43111) ‘attr(namespace|local)’ and ‘clamp(none)’ (@Loirooriol, #43045) (@longvatrong111, @mrobinson, #42529, #43105, #43107) values ‘jump-start’, ‘jump-end’, ‘jump-none’, and ‘jump-both’ (@yezhizhen, #43061) Plus a bunch of new DOM APIs: CommandEvent (@lukewarlow, #43190) moveBefore() on Node (@lukewarlow, #41238) relatedTarget on MouseEvent and PointerEvent (@simonwuelker, #42989) command on HTMLButtonElement (@lukewarlow, #43190) selectedOptions on HTMLSelectElement (@jakubadamw, #43017) url on LargestContentfulPaint (@shubhamg13, #42901, #42949) crypto.subtle.digest() for TurboSHAKE (@kkoyung, #43551) crypto.subtle.getPublicKey() for ECDH, ECDSA, Ed25519, RSASSA-PKCS1-v1_5, RSA-PSS, RSA-OAEP, and X25519 (@kkoyung, @Taym95, #43073, #43093, #43106, #43115) servoshell is now installed as servoshell or servoshell.exe, rather than servo or servo.exe (@jschwe, @mrobinson, #42958). --userscripts has been removed for now, but anyone who uses it is welcome to reinstate it as a wrapper around UserContentManager::add_script (@jschwe, #43573). We’ve fixed a bug where link hover status lines are sometimes not legible (@simartin, #43320), and we’re working on getting servoshell signed for macOS to avoid getting blocked by Gatekeeper (@jschwe, #42912). After a long effort by @valpackett, @dlrobertson, and more recently @nortti0 and @sagudev (#43116, #43134), we can now build Servo for FreeBSD! Note that Servo 0.1.0 still has some issues that need to be worked around, but you can get all the details in #44601. A great deal of work went into making the crates.io release possible, including renaming libservo to just servo (@jschwe, #43141), making each package self-contained (@jschwe, #43180, #43165), fixing build issues (@delan, @jschwe, #43170, #43458, #43463) and crates.io compliance issues (@jschwe, #43459), configuring package metadata (@jschwe, @StaySafe020, #43078, #43264, #43451, #43457, #43654), and organising our dependency tree (@jschwe, @yezhizhen, @webbeef, @mrobinson, #42916, #43243, #43263, #43516, #43526, #43552, #43615, #43622, #43273, #43092). As a result, you can now take your first step towards embedding Servo in a Rust app with: $ cargo add servo This is another big update, so here’s an outline: Security Work in progress For developers Embedding and automation More on the web platform Performance and stability Security crypto.subtle.deriveBits() for X25519 checking for all-zero secrets, and verify() for HMAC comparing signatures, are now done in constant time (@kkoyung, #43775, #43773). ‘Content-Security-Policy’ now handles redirects correctly (@TimvdLippe, #43438), and sends violation reports with the correct blockedURI and referrer (@TimvdLippe, #43367, #43645, #43483). The policy in now combines with the policy sent in HTTP headers, rather than overriding it (@TimvdLippe, @elomscansio, #43063). When checking nonces, we now reject elements with duplicate attributes (@dyegoaurelio, #43216). The document containing an can no longer access the contents of error pages (@TimvdLippe, #43539), and CSP violations inside an are now correctly reported (@TimvdLippe, #43652). Work in progress We’ve landed more work towards supporting IndexedDB, under --pref dom_indexeddb_enabled (@arihant2math, @gterzian, @Taym95, @jerensl, #42139, #42727, #43096, #43041, #42451, #43721, #43754, #42786), and towards supporting IntersectionObserver, under --pref dom_intersection_observer_enabled (@stevennovaryo, @mrobinson, #42251). We’re continuing to implement document.execCommand() for rich text editing (@TimvdLippe, #43177), under --pref dom_exec_command_enabled. ‘beforeinput’ and ‘input’ events are now fired when executing supported and enabled commands (@TimvdLippe, #43087), the ‘defaultParagraphSeparator’ and ‘styleWithCSS’ commands are now supported (@TimvdLippe, #43028), and the ‘delete’ command is partially supported (@TimvdLippe, #43016, #43082). We’re also working on the Font Loading API (@simonwuelker, #43286), under --pref dom_fontface_enabled. new FontFace() now accepts ArrayBuffer in its source argument (@simonwuelker, #43281). All of the features above are enabled in servoshell’s experimental mode. Work on accessibility support for web contents continues under --pref accessibility_enabled. There was a breaking change in the embedding API (@delan, @alice, #43029), and we’ve landed support for “grafting” the accessibility tree of a document into that of its containing webview (@delan, @alice, #43012, #43013, #43556). As a result, when you navigate, separate documents can have separate accessibility trees without complicating the embedder. is now partially supported (@Gae24, #42964), though recursive fetching of descendants is gated by --pref dom_allow_preloading_module_descendants (@Gae24, #43353). For a long time, Servo has had some support for the Web Bluetooth API under --pref dom_bluetooth_enabled. We’ve recently reworked our implementation to adopt btleplug, the cross-platform Rust-native Bluetooth LE library (@webbeef, #43529, #43581). We’re now implementing the Web Animations API, starting with AnimationTimeline and DocumentTimeline (@mrobinson, #43711). We’ve landed more fixes to Servo’s async parser (@simonwuelker, #42930, #42959), under --pref dom_servoparser_async_html_tokenizer_enabled. If we can get the feature working more reliably (#37418), it could halve the energy Servo spends on parsing, lower latency for pages that don’t use document.write(), and even improve the html5ever API for the ecosystem. For developers Servo’s DevTools feature now has partial support for inspecting service workers (@CynthiaOketch, #43659), as well as using the navigation controls along the top of the UI (@brentschroeter, @eerii, #43026). In the Inspector tab, we’ve fixed a bug where the UI stops updating when navigating to a new page (@brentschroeter, #43153). In the Console tab, you can now evaluate JavaScript in web workers and service workers (@SharanRP, #43361, #43492). In the Debugger tab, you can now Step In, Step Out, and Step Over (@eerii, @atbrakhi, #42907, #43040, #43042, #43135). We’ve landed partial support for the Scopes panel (@eerii, @atbrakhi, #43166, #43167, #43232), the Call stack panel (@atbrakhi, @eerii, #43015, #43039), and showing you information when hovering over objects, arrays, functions, and other values (@atbrakhi, @eerii, #43319, #43356, #43456, #42996, #42936, #42994). We’ve fixed some long-outstanding bugs where the DevTools UI may stop responding due to protocol desyncs (@brentschroeter, @eerii, #43230, #43236), or due to messages from multiple Servo threads being interleaved (@brentschroeter, @eerii, #43472). For developers of Servo itself, mach can be a bit opaque at times. To make mach more transparent and composable, we’ve added mach print-env and mach exec commands (@jschwe, #42888). We’re also working on a new dev container, which will provide an alternative to our usual procedures for setting up a Servo build environment (@jschwe, @sagudev, #43127, #43131, #43139). Embedding and automation Breaking changes: Servo::set_accessibility_active() is now WebView::set_accessibility_active() (@delan, @alice, #43029), to make the API harder to misuse (see the docs for more details). What was previously named WebView::pinch_zoom() has been renamed to adjust_pinch_zoom(), and we’ve added a pinch_zoom() method that lets you read the current pinch zoom level (@chrisduerr, #43228). WebView::set_delegate(), set_clipboard_delegate(), and set_gamepad_provider() are now WebViewBuilder::delegate(), clipboard_delegate(), and gamepad_delegate() (@mrobinson, #43205, #43233). Note that set_gamepad_provider() is now gamepad_delegate(), consistent with the GamepadProvider rename below. WebViewDelegate::show_bluetooth_device_dialog() has been reworked to use the same “request object” pattern as the request_*() methods, giving you a BluetoothDeviceSelectionRequest with clear methods (@webbeef, #43580). GamepadProvider has been renamed to GamepadDelegate, and gamepad_provider() on WebView has been renamed to gamepad_delegate() (@mrobinson, #43233). The empty default implementation of EventLoopWaker::wake has been removed, because it almost never makes sense for a new custom impl to leave the method empty (@chrisduerr, @mrobinson, #43250). Opts::print_pwm is now DiagnosticsLogging::progressive_web_metrics (@mrobinson, #43209). Removed from our API: Opts::nonincremental_layout (@mrobinson, #43207) – no replacement. This only really worked in legacy layout. Opts::user_stylesheets (@mrobinson, #43206) – use UserContentManager::add_stylesheet() instead. This is how servoshell’s --user-stylesheet option works. You can now read and write cookies with SiteDataManager::cookies_for_url() and set_cookie_for_url() (@longvatrong111, #43600). ClipboardDelegate and StringRequest are now exposed to the public API, allowing you to implement custom clipboard delegates (@jdm, @chrisduerr, #43203, #43261). You can pass your custom delegate to WebViewBuilder::clipboard_delegate(). You can now get the EmbedderControlId associated with an InputMethodControl by calling InputMethodControl::id() (@chrisduerr, #43248). PixelFormat now implements Debug (@chrisduerr, @mrobinson, #43249). We’ve improved the docs for Servo, ServoBuilder, WebViewBuilder, RenderingContext (@chrisduerr, #43229), EmbedderControlId, EmbedderControlRequest, EmbedderControlResponse, SimpleDialogRequest, AlertResponse, ConfirmResponse, PromptResponse, EmbedderMsg (@mukilan, #43564), ResourceReaderMethods (@jschwe, @mrobinson, #43769), servo::input_events (@mukilan, #43681), and WheelDelta (@yezhizhen, @mrobinson, #43210). We fixed a deadlock in WebDriver that occurs under heavy use of actions from multiple input sources (@yezhizhen, #43202, #43169, #43262, #43275, #43301), ‘pointerMove’ actions with a ‘duration’ are now smoothly interpolated (@yezhizhen, #42946, #43076). Add Cookie is now more conformant (@yezhizhen, #43690), which led to Servo developers landing a spec patch. ‘pause’ actions are now slightly more efficient (@yezhizhen, #43014), and we’ve fixed a bug where ‘wheel’ actions fail to interleave with other actions (@yezhizhen, #43126). More on the web platform Carets now blink in text fields (@mrobinson, #43128). You can configure or disable blinking carets with --pref editing_caret_blink_time=0 or a duration in milliseconds. Clicking to move the caret is more forgiving now (@mrobinson, #43238), and moving the caret by a word at a time is more conventional on Windows and Linux, with Ctrl instead of Alt (@mrobinson, #43436). We’ve also fixed a bug where pressing the arrow keys in text fields both moves the caret (good) and scrolls the page (bad), and fixed a bug where the caret fails to render on empty lines (@mrobinson, @freyacodes, #43247, #42218). Input has improved, with more responsive touchpad scrolling on Linux (@mrobinson, @chrisduerr, #43350). Pointer events and mouse events can now be captured across shadow DOM boundaries (@simonwuelker, #42987), and we’ve now started working towards shadow-DOM-compatible focus (@mrobinson, #43811). Pressing Space or Enter inside text fields no longer causes them to be clicked (@mrobinson, #43343). The lang attribute is now taken into account when shaping, which is important for the correct rendering of Chinese and Japanese text (@RichardTjokroutomo, @mrobinson, #43447). ‘font-weight’ is now matched more accurately when no available font is an exact match (@shubhamg13, #43125). Navigation is one of the most complicated parts of HTML: navigating can run some JavaScript that replaces the page, just run some JavaScript, or depending on the response, do nothing at all. makes navigation doubly complicated: the document containing an can observe and interact with the document inside the in various ways, often synchronously. This has been the source of many bugs over the years, but we’ve recently fixed one of those major issues (@jdm, #43496). javascript: URLs are a massive special case with many quirks, and has its own big edge cases. new Worker() now supports JS modules (@pylbrecht, @Gae24, #40365), and CanvasRenderingContext2D now supports drawing text with Variation Selectors, allowing you to control things like emoji presentation and CJK shaping (@yezhizhen, #43449). Servo now fires ‘pointerover’, ‘pointerout’, ‘pointerenter’, and ‘pointerleave’ events on web content (@webbeef, #42736), ‘scroll’ events on VisualViewport (@stevennovaryo, #42771), and ‘scrollend’ events on Document, Element, and VisualViewport (@abdelrahman1234567, @mrobinson, #38773). We also fire ‘error’ events when event handler attributes contain syntax errors (@simonwuelker, #43178). We’ve improved the default appearance of (@Loirooriol, #43111), (@lukewarlow, #43175), (@lukewarlow, @AlexVasiluta, @lukewarlow, #43498, #43186), and and and friends (@mrobinson, #43132), plus ‘::marker’ in mixed LTR/RTL content (@Loirooriol, #43201). also now requires user interaction to open the picker (@SharanRP, #43485). , , open(url) on XMLHttpRequest, new EventSource(url), and new Worker(url) now correctly resolve the URL with the page encoding (@SharanRP, @jdm, @jayant911, @Veercodeprog, @sabbCodes, #43521, #43554, #43572, #43537, #43634, #43588). ‘direction’ now works on grid containers (@nicoburns, #42118), SVG images can now be used in ‘border-image’ (@shubhamg13, #42566), ‘linear-gradient()’ now dithers to reduce banding (@Messi002, #43603), ‘letter-spacing’ no longer applies to invisible zero-width formatting characters (@simonwuelker, #42961), and ‘:active’ now matches disabled or non-focusable elements too, as long as they are being clicked (@webbeef, #42935). DOMContentLoaded timings in PerformanceNavigationTiming are more accurate (@simonwuelker, #43151). PerformancePaintTiming and LargestContentfulPaint are more accurate too, taking into account (@shubhamg13, #42149), and checking for and ignoring things like broken images and transparent backgrounds (@shubhamg13, #42833, #42975, #43475). We’ve improved the conformance of JS modules (@Gae24, #43585), (@lukewarlow, #42883), (@shubhamg13, #43103), and (@TimvdLippe, #43043), (@SharanRP, #43582), and (@Gae24, #42931), EventSource (@mishop-15, #42179), SubtleCrypto (@kkoyung, #42984, #43315, #43533, #43519), Worker (@simonwuelker, #43329), HTMLVideoElement (@shubhamg13, #43341), dataset on Element (@TimvdLippe, #43046), and querySelector() and querySelectorAll() (@simonwuelker, #42991). We’ve fixed bugs related to error reporting (@simonwuelker, @xZaisk, @yezhizhen, @eyupcanakman, #43191, #43323, #43101, #43560), event loops (@jayant911, #43523), focus (@jakubadamw, #43431), quirks mode (@mrobinson, @Loirooriol, @lukewarlow, #42960, #43368), (@TimvdLippe, @jdm, #43539, #43732), the ‘animationstart’ and ‘animationend’ events (@simonwuelker, #43454), the ‘touchmove’ event (@yezhizhen, #42926), CanvasRenderingContext2D (@simonwuelker, #43218), Worker (@bruno-j-nicoletti, #43213), ‘:active’ on (@mrobinson, #43722), ‘overflow: scroll’ on ‘::before’ and ‘::after’ (@stevennovaryo, #43231), ‘position: absolute’ (@yoursanonymous, @Loirooriol, #43084), and and without width or height attributes (@Loirooriol, #42666). Fixing that last bug led to Servo developers finding two spec issues! We’ve landed partial support for using CSS counters in ‘list-style-type’ on ‘display: list-item’ and ‘content’ on ‘::marker’, but the counter values themselves are not calculated yet, so all list items still read as 0. or similar. In any case, you can use a or ‘symbols()’ in ‘list-style-type’, and ‘counter()’ and ‘counters()’ in ‘content’ (@Loirooriol, #43111). We’ve also landed partial support for and the HTMLMarqueeElement interface, including basic layout, but the contents are not animated yet (@mrobinson, @lukewarlow, #43520, #43610). Servo now exposes several attributes that have no direct effect, but are needed for web compatibility (@lukewarlow, #43500, #43499, #43502, #43518): noHref on HTMLAreaElement hreflang, type, charset on HTMLAnchorElement useMap on HTMLInputElement and HTMLObjectElement longDesc on HTMLIFrameElement and HTMLFrameElement Performance and stability We’ve fixed sluggish scrolling on long documents like this page on docs.rs (@webbeef, @yezhizhen, #43074, #43138), and reduced the memory usage of BoxFragment by 10% (@stevennovaryo, #43056). about:memory now has a Force GC button (@webbeef, #42798), and no longer reports all processes as content processes in multiprocess mode (@webbeef, #42923). Web fonts are no longer fetched more than once, and they no longer cause reflow when they fail to load (@minghuaw, #43382, #43595). We’re also working towards better caching for shaping results (@mrobinson, @lukewarlow, @Loirooriol, #43653). Event handler attribute lookup is more efficient now (@Narfinger, #43337), and we’ve made DOM tree walking more efficient in many cases (@Narfinger, #42781, #42978, #43476). crypto.subtle.encrypt(), decrypt(), sign(), verify(), digest(), importKey(), unwrapKey(), decapsulateKey(), and decapsulateBits() are more efficient now (@kkoyung, #42927), thanks to a recent spec update. More of Servo now uses cheaper crossbeam channels instead of IPC channels, unless Servo is running in multiprocess mode, or avoids IPC altogether (@Narfinger, @jschwe, @Taym95, #42077, #43309, #42966). We’ve also reduced clones, allocations, conversions, comparisons, and borrow checks in many parts of Servo (@simonwuelker, @kkoyung, @mrobinson, @Narfinger, @yezhizhen, @TG199, #43212, #43055, #43066, #43304, #43452, #43717, #43780, #43088, #43226). DOM data structures (#[dom_struct]) can refer to one another, with the help of garbage collection. But when DOM objects are being destroyed, those references can become invalid for a brief moment, depending on the order the GC finalizers run in. This can be unsound if those references are accessed, which is a very easy mistake to make if the type has an impl Drop. To help prevent that class of bug, we’re reworking our DOM types so that none of them have #[dom_struct] and impl Drop at the same time (@willypuzzle, #42937, #42982, #43018, #43071, #43222, #43288, #43544, #43563, #43631). We’ve fixed a crash caused by an IPC resource leak when making many requests over time (@yezhizhen, #43381), and some bugs found by ThreadSanitizer and --debug-mozjs (@jdm, @Loirooriol, #42976, #42963, #43487). We’ve also fixed crashes in CanvasRenderingContext2D (@yezhizhen, #43449), Crypto (@rogerkorantenng, #43501), devtools (@simonwuelker, #43133), event handler attributes (@simonwuelker, #43178), Promise (@Narfinger, @jdm, #43470), and WebDriver (@Tarmil, @yezhizhen, #42739, #43381). We’ve continued our long-running effort to use the Rust type system to make certain kinds of dynamic borrow failures impossible (@Narfinger, @Gae24, @Uiniel, @TimvdLippe, @yezhizhen, @sagudev, @PuercoPop, @pylbrecht, @arabson99, @jayant911, #42957, #43108, #43130, #43215, #43183, #43219, #43245, #43220, #43252, #43268, #43184, #43277, #43278, #43284, #43302, #43312, #43348, #43327, #43362, #43365, #43383, #43432, #43259, #43439, #43473, #43481, #43480, #43479, #43525, #43535, #43543, #43549, #43570, #43571, #43569, #43579, #43584, #43657, #43713). Thanks to a wide range of people, many of whom were contributing to Servo for their first time, we’ve also landed a bunch of architectural improvements (@elomscansio, @mukilan, #43646), cleanups (@simartin, @SharanRP, @TG199, @sabbCodes, @niyabits, @eerii, @atbrakhi, #43276, #43285, #43532, #43778, #43771, #43566, #43567, #43587, #43140, #43316), and refactors (@sabbCodes, @arabson99, @jayant911, @StaySafe020, @saydmateen, @eerii, @TimvdLippe, @elomscansio, @CynthiaOketch, #43614, #43641, #43619, #43642, #43623, #43656, #43644, #43672, #43664, #43676, #43684, #43679, #43678, #43655, #43675, #43731, #43729, #43728, #43740, #43751, #43748, #43747, #43752, #43745, #43724, #43723, #43765, #43767, #43181, #43269, #43270, #43279, #43437, #43597, #43607, #43602, #43616, #43609, #43612, #43647, #43651, #43662, #43714, #43774). Donations Thanks again for your generous support! We are now receiving 7167 USD/month (+2.6% from February) in recurring donations. This helps us cover the cost of our speedy CI and benchmarking servers, one of our latest Outreachy interns, and funding maintainer work that helps more people contribute to Servo. Servo is also on thanks.dev, and already 37 GitHub users (+5 from February) that depend on Servo are sponsoring us there. If you use Servo libraries like url, html5ever, selectors, or cssparser, signing up for thanks.dev could be a good way for you (or your employer) to give back to the community. We now have sponsorship tiers that allow you or your organisation to donate to the Servo project with public acknowlegement of your support. If you’re interested in this kind of sponsorship, please contact us at join@servo.org. 7167 USD/month 10000 Use of donations is decided transparently via the Technical Steering Committee’s public funding request process, and active proposals are tracked in servo/project#187. For more details, head to our Sponsorship page.

The Rust Programming Language Blog: Announcing Google Summer of Code 2026 selected projects

Thu, 30 Apr 2026 02:00:00 +0200

As previously announced, the Rust Project is participating in Google Summer of Code (GSoC) 2026. GSoC is a global program organized by Google that is designed to bring new contributors to the world of open source. A few months ago, we published a list of GSoC project ideas, and started discussing these projects with potential GSoC applicants on our Zulip. We had many interesting discussions with the potential contributors, and even saw some of them making non-trivial contributions to various Rust Project repositories before GSoC officially started! The applicants prepared and submitted their project proposals by the end of March. This year, we received 96 proposals, which is a 50% increase from last year. We are glad that there was again a lot of interest in our projects! Like many other GSoC organizations this year, we somewhat struggled with some AI-generated proposals and low-quality contributions generated using AI agents, but it stayed manageable. GSoC requires us to produce an ordered list of the best proposals, which is always challenging, as Rust is a big project with many priorities. Our mentors examined the submitted proposals and evaluated them based on their prior interactions with the given applicant, their contributions so far, the quality of the proposal itself, but also the importance of the proposed project for the Rust Project and its wider community. We also had to take mentor bandwidth and availability into account. Unfortunately, we had to cancel some projects due to several mentors losing their funding for Rust work in the past few weeks. As is usual in GSoC, even though some project topics received multiple proposals1, we had to pick only one proposal per project topic. We also had to choose between proposals targeting different work to avoid overloading a single mentor with multiple projects. In the end, we narrowed the list down to the best proposals that we could still realistically support with our available mentor pool. We submitted this list and eagerly awaited how many of them would be accepted into GSoC. Selected projects On the 30th of April, Google has announced the accepted projects. We are happy to share that 13 Rust Project proposals were accepted by Google for Google Summer of Code 2026. That is a lot of projects! We are really happy and excited about GSoC 2026! Below you can find the list of accepted proposals (in alphabetical order), along with the names of their authors and the assigned mentor(s): A Frontend for Safe GPU Offloading in Rust by Marcelo Domínguez, mentored by Manuel Drehwald Adding WebAssembly Linking Support to Wild by Kei Akiyama, mentored by David Lattimore Bringing autodiff and offload into Rust CI by Shota Sugano, mentored by Manuel Drehwald Debugger for Miri by Mohamed Ali Mohamed, mentored by Oli Scherer Implementing impl and mut restrictions by Ryosuke Yamano, mentored by Jacob Pratt and Urgau Improving Ergonomics and Safety of serialport-rs by Tanmay, mentored by Christian Meusel libc: transition differing bit-width time and offset variants and deprecate bug-prone constants by Adam Martinez, mentored by Trevor Gross Link Linux kernel and its Modules with Wild by Vishruth Thimmaiah, mentored by David Lattimore Migrating rust-analyzer assists to SyntaxEditor by Shourya Sharma, mentored by Chayim Refael Friedman and Lukas Wirth Port std::arch test suite to rust-lang/rust by Sumit Kumar, mentored by Jakub Beránek and Folkert de Vries Reorganizing tests/ui/issues by zedddie, mentored by Teapot and Kivooeo Utilize debugger APIs to improve debug info test accuracy and error reporting by Anthony Bolden, mentored by Jakub Beránek and Jieyou Xu XDG path support for rustup by Guicheng Liu, mentored by rami3l Congratulations to all applicants whose project was selected! Our mentors are looking forward to working with you on these exciting projects to improve the Rust ecosystem. You can expect to hear from us soon, so that we can start coordinating the work on your GSoC projects. We are excited to mentor three contributors who already experienced GSoC with us in the previous year. Welcome back, Kei, Marcelo and Shourya! We would like to thank all the applicants whose proposal was sadly not accepted, for their interactions with the Rust community and contributions to various Rust projects. There were some great proposals that did not make the cut, in large part because of limited mentorship capacity. However, even if your proposal was not accepted, we would be happy if you would consider contributing to the projects that got you interested, even outside GSoC! Our project idea list is still current and could serve as a general entry point for contributors that would like to work on projects that would help the Rust Project and the Rust ecosystem. Some of the Rust Project Goals are also looking for help. There is a good chance we'll participate in GSoC next year as well (though we can't promise anything at this moment), so we hope to receive your proposals again in the future! The accepted GSoC projects will run for several months. After GSoC 2026 finishes (in autumn of 2026), we will publish a blog post in which we will summarize the outcome of the accepted projects. The most popular project topic received fourteen different proposals! ↩

Mozilla Data YouTube Channel: Outreachy Mentorship: A Retrospective

Thu, 30 Apr 2026 09:37:48 +0200

Will Lachance does a retrospective on the Glean Dictionary outreachy internship. See also "Linh's Outreachy Internship Highlights" https://www.youtube.com/watch?v=UJdIkHDPgGQ To learn more about Outreachy, see https://www.outreachy.org/

Mozilla Localization (L10N): L10n Report: April Edition 2026

Thu, 30 Apr 2026 08:13:53 +0200

Please note some of the information provided in this report may be subject to change as we are sometimes sharing information about projects that are still in early stages and are not final yet. Welcome! Are you a locale leader and want us to include new members in our upcoming reports? Contact us! What’s new or coming up in Firefox desktop Firefox string deadline changes Starting with 149, some changes in developer deadlines relating to Nightly and Beta have resulted in a slight shift in string translation deadlines, giving us 2 extra days to land strings. Previously deadlines in Pontoon were set to the Sunday ahead of the final Release Candidate but going forward they will be set to a Tuesday. For example the upcoming deadline for Firefox 151 is Tuesday, May 12. If you’re interested to see more details on upcoming Firefox releases and milestones, https://whattrainisitnow.com has all the latest details. UI Refresh Behind the scenes a refresh on the visual look of Firefox has been ongoing using the internal name “Nova”. You may have seen some blog reports recently on this, or perhaps have been seeing bugs in Bugzilla with this in the title. We will start seeing new strings related to these changes here and there as development work progresses, however we don’t expect a large number of string changes stemming from this work. That being said, these updates also bring some changes in how we communicate directly to our users within Firefox. One of these changes you may have already met: our new mascot Kit. If you missed the announcement give it a read here. You may also notice a shift voice for user directed messages — with source strings becoming more Genuine, Fiery, and Playful. See this recent update in Firefox’s brand voice for more details. Settings redesign Localization for the update to about:settings has been going on for some time (starting early this year) and the bulk of the translation work is behind us at this point. You may see some new strings (particularly around Privacy & Security) but many of the strings are in a viewable/testable state in Nightly 152. You can check your translations and test out the redesign by typing about:config into your URL bar, proceeding past the warning message, and searching for browser.settings-redesign.enabled and setting the value to true. What’s new or coming up in mobile Things have been particularly busy on mobile over the past couple of months. For example, Firefox for Android saw a significant spike in April, with the number of new strings increasing to over 200 compared to fewer than 50 in March — more than eight times the typical monthly volume*. There are two main drivers behind this increase. First, Firefox for Android is introducing a built-in VPN feature, bringing it in line with the functionality already available in Firefox. Second, both iOS and Android teams are working on a new widget for the upcoming 2026 World Cup, allowing users to follow their team directly from the browser. Given the short turnaround time for this feature, you will notice that many strings are intentionally kept consistent across platforms — and started landing on Desktop as well. We’re also pre-landing as many strings as possible, ahead of implementation, to give localizers more time to complete translations. * Did you know that you can track the number of new strings in a project from the Insights page in Pontoon? Check for example Firefox for Android. In the Translation activity chart, click on New source strings in the legend to display this data. Given the difference in scale, it can also help to hide other metrics to make the chart easier to read. What’s new or coming up in Pontoon New documentation system. Pontoon now features a brand-new, unified documentation system. This new hub brings together previously scattered resources into a single, streamlined experience, consolidating developer, localizer, and admin documentation from three separate sites into one cohesive platform. By centralizing content, the new system makes it easier to find, navigate, and maintain documentation, ensuring contributors of all roles have quick access to up-to-date and consistent guidance. Search. You can now set default search options directly in your profile. This allows you to tailor your search without having to adjust filters each time. The same settings are also applied when using the recently introduced global search page, which brings a major step forward in unifying localization across Mozilla by allowing users to search for strings across all projects and locales in one place. Inspired by Transvision and designed as its successor, the feature integrates deeply with Pontoon, making it easy to filter results, compare translations across languages, and jump directly into the translation workflow. AI integration. We’ve also refined the prompt used by the LLM-powered translation feature. The goal is not to change how the feature works, but to make its output more consistent and better aligned with the context available in Pontoon. For example, the updated prompt improves how punctuation is handled, reducing variability in suggestions. In addition, the prompt now includes more contextual data: String ID. Comments, including pinned comments from project managers. Matches from terminology. This additional context helps the model generate more relevant suggestions. It also represents a first step toward making LLM suggestions more useful, ahead of potential experiments with displaying them by default alongside suggestions from traditional machine translation. New contributors. We’re also excited to welcome a group of new contributors who have started making an impact on Pontoon over the past few months. MundiaNderi, nishitmistry, dannycolin, first-afk, wassafshahzad, huseynovvusal, and Peacanduck have all contributed valuable improvements across different parts of the project, helping us move faster and improve the overall experience. A special shoutout goes to Serah (MundiaNderi), who not only made significant contributions but also shared insights into her work in a recent blog post about enhancing comment management in Pontoon—an excellent example of the kind of collaboration and knowledge sharing we love to see in the community. Newly published localizer facing documentation As part of the recent documentation update for Pontoon, we’ve reorganized the content around pretranslation to make it clearer and easier to navigate. There is now a dedicated page outlining the criteria required to enable pretranslation for a locale, along with guidance on how to monitor its effectiveness over time (for example, by tracking metrics like acceptance rate or time to review). If you’re a locale manager and want to try pretranslation for your locale, you can request it directly from Pontoon. Over the past 12 months, we also ran a limited experiment using paid translation agencies for two locales. The goal was to restore the localization level of Firefox for Android in cases where the community was inactive — situations that have since improved, with both communities now active again. Because volunteer communities remain the foundation of Mozilla’s localization model, we wanted to be transparent about when and why this approach was used, and what it means in practice. This includes clarifying how external support fits within a community-driven ecosystem, where localizers retain ownership and responsibility for quality and direction. You can find more details in this page. Friends of the Lion Image by Elio Qoshi We continue the localizer spotlight series this year. Meet Oliver from China Firefox localizer, accounting student, former Minecraft translator, and Bocchi the Rock! fan He talks about starting with a single typo, why Firefox’s independence matters to him, and how the Simplified Chinese community keeps quality high with cross-review and shared responsibility. Marcelo from Argentina needs no introduction to the localization communities. From Phoenix 0.3 to 24 years later, he shares how he got started, what it meant to be part of the Firefox 1.0 release, his experience as an l10n manager, and why using Mozilla products in his own language — Spanish (Argentina) — continues to motivate him. What does 18 years of volunteer localization look like? From discovering Firefox and Linux out of curiosity to leading the Portuguese translation team, Cláudio from Portugal reflects on why localization is a form of digital activism, and how every translated word helps build a more inclusive internet. Baurzhan from Kazakhstan began his localization journey with a simple question: why wasn’t Kazakh available in widely used software? That curiosity grew into a long-term commitment to localization, leading to the successful translation of Firefox and many other open source projects. His work demonstrates the power of perseverance in making technology accessible to all. If you enjoy the series, please help us identify the localizers you’d like to see featured filling out this nomination form. If you have stories to share, tell us in your own words. Know someone in your l10n community who’s been doing a great job and should appear here? Contact us and we’ll make sure they get a shout-out! Useful Links #l10n-community channel on Element (chat.mozilla.org) Localization category on Discourse Mastodon Twitter L10n blog Questions? Want to get involved? If you want to get involved, or have any question about l10n, reach out to: Francesco Lodolo (flod) – Engineering Manager Bryan – L10n Project Manager Peiying (CocoMo) – L10n Project Manager for mozilla.org, marketing, and legal Francis – L10n Project Manager for Common Voice, Mozilla Foundation Théo Chevalier – L10n Project Manager for Mozilla Foundation Kiki – L10n Project Manager for SUMO Matjaž (mathjazz) – Pontoon dev Eemeli – Pontoon, Fluent dev Did you enjoy reading this report? Let us know how we can improve it.

The Mozilla Blog: Welcoming Abigail Besdin, Mozilla’s new Chief Operating Officer

Thu, 30 Apr 2026 14:57:15 +0200

We’re delighted that Abigail Besdin has joined Mozilla as our new Chief Operating Officer. This is an incredibly exciting time for Mozilla. Our focus is to become the world’s most trusted software company by building products that let people use the internet openly, safely, and on their terms. As technology changes rapidly, we are working to strengthen the business foundation and infrastructure that champions our mission. Delivering on that ambition takes more than great products; it demands operational rigor. Abigail will lead this effort, demonstrating how values-driven organizations can scale with discipline, speed, and trust in the AI era. As COO, Abigail will drive company strategy and oversee Mozilla’s Core Services teams: Business Operations, Data, Infrastructure, IT, Legal, People, Security, and Strategy. These are the functions that enable us to move quickly and scale with focus. Abigail will sharpen how we plan, prioritize, and execute across the company. Abigail brings more than 18 years of experience building and scaling high-impact platforms. She co-founded Great Jones, a venture-backed property management startup where she raised $30M, reached $10M in ARR, and led a successful acquisition by Roofstock. At Roofstock, she served as Chief of Staff to the CEO — functioning as an internal COO — where she launched new product lines, closed and integrated two acquisitions, and led the company’s strategic planning process. Earlier in her career, she spent six years at Skillshare, where she launched the company’s online learning platform and built its growth and content engines from the ground up. That combination of founder’s instinct and operator’s discipline is exactly what Mozilla needs right now. Abigail will report directly to our CEO and join the executive team. I’ve learned firsthand that ambitious product goals are only as effective as the operations underpinning them. Mozilla’s mission is as big as it gets, and I’m thrilled to lead our Core Services organization to enable rigorous, smart, and quick decision-making across the business. With a powerful execution engine, we can make sure the best of Mozilla’s mission materializes. Abigail Besdin, Chief Operating Officer Abigail studied Philosophy at NYU, with a focus on Ethics and Mathematical Logic. Born and raised in New York City, she still lives there with her husband and three kids. Please join us in welcoming Abigail to Mozilla. The post Welcoming Abigail Besdin, Mozilla’s new Chief Operating Officer appeared first on The Mozilla Blog.

Firefox Tooling Announcements: Firefox Profiler Deployment (April 28, 2026)

Thu, 30 Apr 2026 14:09:45 +0200

The latest version of the Firefox Profiler is now live! Check out the full changelog below to see what’s changed: Highlights: [fatadel] Dim non-matching nodes in the stack chart when searching (#5935) [Markus Stange] Always render the CPU-usage-aware activity graph when CPU information is available (#5918) [fatadel] Add CounterDisplayConfig to counters in the processed profile format (#5912) [Nazım Can Altınova] Fallback to javascript highlighting in the source view as a backup (#5936) [fatadel] Replace 4 counter track components with a single generic TrackCounter (#5944) [Ryan Hunt] Add a fullscreen button to the bottom box (#5605) [Nazım Can Altınova] Add “Include idle samples” toggle to the call tree settings (#5968) [Markus Stange] Update the hovered item when panning any viewport canvas (#5903) [Nazım Can Altınova] Fix loading .json.gz profiles from inside zip archives (#5959) [Markus Stange] Replace symbolicator-cli with a profiler-edit node tool (#5965) Other Changes: [fatadel] Fix arrow panel appearing behind marker tooltips (#5926) [fatadel] Upgrade Node.js from v22 to v24 (#5923) [Markus Stange] Use createStackTableBySkippingDiscarded in focusSelf. (#5916) [Markus Stange] Propagate isJS to symbolicated funcs (#5907) [Nazım Can Altınova] Properly type the return value of _languageExtForPath (#5937) [Nazım Can Altınova] Update typescript eslint dependencies (#5938) [Markus Stange] Modernize more of the transform functions (#5934) [Paul Adenot] Fix extractGeckoLogs for structured Log marker format (bug 2022540) (#5927) [Nazım Can Altınova] Move some profile fetching code into a separate module. (#5939) [Markus Stange] Migrate Home page animation to CSS transitions and remove react-transition-group (#5649) [Nazım Can Altınova] Fix test/lint commands on Windows and fix CI (#5947) [Nazım Can Altınova] Convert profile-logic/js-tracer.tsx to a ts file (#5942) [Markus Stange] Remove panelLayoutGeneration (#5946) [Nazım Can Altınova] Fix eslint-config-prettier silently overriding custom rules (#5955) [Markus Stange] Speed up _computeCallNodeTableHierarchy by keeping siblings ordered by func (#5964) [Nazım Can Altınova] Add dark mode versions of the fullscreen icons (#5972) [fatadel] Use ephemeral port for esbuild’s internal dev server (#5974) [carverdamien] Remove category from LongTaskMarkerPayload (#5975) Big thanks to our amazing localizers for making this release possible: de: Ger de: Michael Köhler el: Jim Spentzos en-GB: Ian Neal es-CL: ravmn fr: Théo Chevalier ia: Melo46 it: Francesco Lodolo [:flod] nl: Mark Heijl pt-BR: Marcelo Ghelman ru: Valery Ledovskoy ru: berry sv-SE: Andreas Pettersson tr: Grk zh-CN: Olvcpr423 zh-CN: wxie zh-TW: Pin-guang Chen Find out more about the Firefox Profiler on profiler.firefox.com! If you have any questions, join the discussion on our Matrix channel! 1 post - 1 participant Read full topic

William Durand: Moziversary #8

Fri, 01 May 2026 02:00:00 +0200

Today is my eighth Moziversary 🎂 I joined Mozilla as a full-time employee on May 1st, 2018. I previously blogged in 2019, 2020, 2021, 2022, 2023, 2024, and 2025. You might have come across this built-in data consent thing for extensions in Firefox. I spent a good chunk of last year working on this project, from developing a technical proposal to implementing the feature in Gecko, Firefox for desktop and Firefox for Android. Talking about Android, I became the module owner for Fenix::Add-ons, a module for all the code related to add-ons in Firefox for Android (which we call “Fenix” internally). Between the creation of this new module, and an ever-solidifying collaboration between the Add-ons and Android teams, the support for extensions in Firefox for Android has a bright future! Having started my Android journey in 2023, this feels like a noteworthy achievement. Near the end of last year, I moved back to being a full-time AMO engineer to support a team that was down to two engineers. I redesigned the detail page, and started some refactoring on our security scanners, which I had originally created back in 2019 😬 In other news, I joined the AI/LLM/vibe-coding crowd thanks to my colleague Paul, and it took me about a month to get brain-fried… AI fatigue is real, indeed. That said, Claude code has been somewhat useful to me, and I don’t hate it, but I also don’t love it. Thank you to everyone in the Add-ons team as well as to all the folks I had the pleasure to work with so far. Cheers!

The Rust Programming Language Blog: Raising the baseline for the `nvptx64-nvidia-cuda` target

Fri, 01 May 2026 02:00:00 +0200

The nvptx64-nvidia-cuda target is a compilation target for NVIDIA GPUs. When using this target, the final output is PTX. Two version choices shape that output: a GPU architecture (for example, sm_70, sm_80, …), which determines which GPUs can run the PTX, and a PTX ISA version, which determines which CUDA driver versions can load (and JIT-compile) the PTX. In Rust 1.97 (scheduled for release on July 9, 2026), the baseline PTX ISA version and GPU architecture for nvptx64-nvidia-cuda will be increased. These changes affect both the Rust compiler (rustc) and related host tooling, and they make it impossible to generate PTX artifacts compatible with older GPUs and older CUDA drivers. The new minimum supported versions will be: PTX ISA 7.0 (requires a CUDA 11 driver or newer) SM 7.0 (GPUs with compute capability below 7.0 are no longer supported) Why are the requirements being changed? Until now, Rust has supported emitting PTX for a wide range of GPU architectures and PTX ISA versions. In practice, several defects existed that could cause valid Rust code to trigger compiler crashes or miscompilations. Raising the baseline addresses these issues and enables more complete support for the remaining supported hardware. Removing support affects users of the architectures being removed. In this case, the most recent affected GPU architectures date back to 2017 and are no longer actively supported by NVIDIA. We therefore expect the overall impact of this change to be limited. Maintaining support for these architectures would require substantial effort. These removals let us focus development efforts on improving correctness and performance for currently supported hardware. What happens when I update to Rust 1.97? If you need to target a CUDA driver that does not support PTX ISA 7.0 (CUDA 10-era drivers and older), Rust 1.97 will no longer be able to generate PTX compatible with that environment. Similarly, if you need to run on GPUs with compute capability below 7.0 (for example, Maxwell or Pascal), Rust 1.97 will no longer be able to generate compatible PTX for those GPUs. Assuming you are targeting a CUDA driver compatible with CUDA 11 or newer and using GPUs with compute capability 7.0 or newer: If you do not specify -C target-cpu, the new default will be sm_70, and your build should continue to work (but will no longer be compatible with pre-Volta GPUs). If you currently specify an older -C target-cpu (for example, sm_60), you will need to either: remove that flag and let it default to sm_70, or update it to sm_70 or a newer architecture. If you already specify -C target-cpu=sm_70 (or newer), there should be no behavioral changes from this update. For more details on building and configuring nvptx64-nvidia-cuda, see the platform support documentation.

Mozilla Data YouTube Channel: Data Club Talk: Jan-Erik Rediger - The Glean UniFFI migration and how no one noticed

Mon, 04 May 2026 19:13:30 +0200

Given at the Mozilla Data Club on August 12th, 2022.

The Rust Programming Language Blog: Rust is participating in Outreachy

Mon, 04 May 2026 02:00:00 +0200

The Rust Project has been building up a good history of participating in various open-source mentorship programs, including Google Summer of Code for three years (including this year) and previously OSPP. We're happy to announce that this year we are also participating in Outreachy starting in the May 2026 cohort. Each of these mentorship programs has different criteria for eligibility depending on who they target and the motivations of the program. Outreachy provides internships in open source, to people from any background who face underrepresentation, systemic bias, or discrimination in the technical industry where they are living. You can learn more about the Outreachy program on their website. What is Outreachy and how is it different than Google Summer of Code Outreachy is similar to Google Summer of Code (GSoC) in some aspects, but different in others. First off, unlike GSoC, Outreachy interns first apply to the overall program and only then can apply to specific communities. Second, while oftentimes GSoC applicants submit various contributions prior to their application, Outreachy has a dedicated period where contributions are not just optional, but required. Finally, Outreachy applicants submit an application similar to GSoC applications and communities pick interns based on those applications and the interns' contributions. Outreachy has two internship periods per year, one running from May to August (in which we are currently participating) and one from December to March. The other major difference between Google Summer of Code and Outreachy is the source of intern stipends. For GSoC, Google graciously covers contributor stipends and overhead. For Outreachy, communities instead cover the interns' stipends and overhead. We are mentoring 4 interns for the May 2026 cohort Because of limited funding availability and mentoring capacity, the Rust Project decided to select four interns for mentorship. We'll briefly share these projects below. Calling overloaded C++ functions from Rust Ajay Singh has been selected, mentored by teor, Taylor Cramer, and Ethan Smith. This project aims to implement an experimental feature for calling overloaded C++ functions from Rust, and to begin testing that feature in a few representative use cases. Code coverage of the Rust compiler at scale Akintewe Oluwasola has been selected, mentored by Jack Huey. This project aims to develop the workflows to run and analyze code coverage of the compiler at the scale of the entire compiler test suite and on ecosystem crates detected by crater. The hope is to be able to detect when the compiler is inadequately tested, both within the compiler and in the ecosystem, and to build tools to do continuous analysis on this. Fuzzing the a-mir-formality type system implementation Tunde-Ajayi Olamiposi has been selected, mentored by Niko Matsakis, Rémy Rakic, and tiif. This project aims to implement fuzzing for a-mir-formality, an in-progress model for Rust's type and trait system. The goal is to generate programs in order to identify rules with underspecified semantics in a-mir-formality. Improve the security of GitHub Actions of the Rust Project oghenerukevwe Sandra Idjighere has been selected, mentored by Marco Ieni and Ubiratan Soares. This project aims to improve the security of GitHub Actions workflows of the repositories owned by the Rust Project. It will develop tools and workflows, integrating with existing software, to analyze Github repositories and detect if they follow the best security practices, fix existing issues, and ensure that good security practices are followed in the future. What's next Over the next 3 months, the interns will work closely with their mentors to make progress on their projects. When the internship period is over, we'll write another blog post to share the results! See you then! We also want to thank all the people that submitted applications and made contributions. It was quite tough to decide which applicants to select. Hopefully we will participate in Outreachy again in the future and there are other opportunities to participate. We also very much welcome you to stick around and continue being involved - there is a ton of places in the Rust Project with opportunities to be involved.

Mozilla Data YouTube Channel: Data Club: Jan-Erik Rediger - Little Bobby Tables - from metrics.yaml to data-filled columns

Mon, 04 May 2026 20:06:43 +0200

A short story about Little Bobby Tables and how we know what data to fill in where.

Mozilla Data YouTube Channel: GLAM Datasets

Tue, 05 May 2026 00:44:24 +0200

Marina Samuel and Anthony Miyaguchi talk about the ETL pipeline created for the GLAM project (https://github.com/mozilla/glam).

Mozilla Data YouTube Channel: Data Club Lightning Talk: Jan-Erik Rediger - Your personal Glean data pipeline

Tue, 05 May 2026 00:23:40 +0200

This talk was given as part of the Data Club Lightning Talk Session on February 11th, 2022. More on https://blog.mozilla.org/data/2022/02/25/this-week-in-glean-your-personal-glean-data-pipeline Information about Glean: https://mozilla.github.io/glean/book/index.html

Mozilla Data YouTube Channel: An opinionated intro to NLP (text analytics)

Tue, 05 May 2026 05:14:33 +0200

Rebecca BurWei from Mozilla Data Science gives an introduction to Natural Language Processing.

Tantek Çelik: May the Focus Be With You!

Tue, 05 May 2026 04:20:00 +0200

Last weekend at IndieWebCamp I noticed James had setup his iPhone in grayscale. I think I first saw that on Jeremy’s phone years ago. I remember trying it on my iPod Touch for a while, eventually switching back to see color photos. This morning while chatting with James I asked him about his grayscale setup and why. He pointed out it’s less distracting, a calmer experience, and helps him stay focused when he uses his iPhone for specific tasks. I decided to give it another try. The setting is quite buried. Here are the items to tap, starting from your home screen, or wherever you moved your ⚙️ Settings app: ⚙️ Settings 🟦 Accessibility > 🟦 Display & Text Size > Color Filters > Color Filters (⚫️__) [slide this toggle to the right to turn it on] Greyscale [tap this and you should see it checked] James said one more setting has helped him stick with grayscale for years now. Triple-press the side button to toggle color/grayscale modes helps quickly switch to color to view a photo or a video, actual color content, then triple-press-side-button to return to a calmer UI. ⚙️ Settings ⏺ Accessibility > ⏺ Accessibility Shortcut > Color Filters [tap this and you should see it checked] In addition, I have found the back-tap feature handy and personally more memorable. Double (or triple) back-tap to toggle color/grayscale mode and toggle back. ⚙️ Settings ⏺ Accessibility > 👆🏻 Touch > Back Tap > Double-tap > Color Filters [tap this and you should see it checked] When using my phone outside in the sun, I noticed the absence of color made it hard to distinguish or even read some things. I changed a few more settings to improve sunlight readability/usability. ⚙️ Settings ⏺ Accessibility > ⏺ Display & Text Size > Bold Text (⚫️__) [tap/slide this toggle to the right to turn it on] Increase Contrast (⚫️__) [tap/slide this too] Differentiate Without Color (⚫️__) [tap/slide this too] In the absence of color on my iPhone, I have spent less time using it today, felt more focused when I used it for a specific task, and have started to feel both less compelled to check things, and less of a “rush” when interacting with iPhone apps and their user interfaces. Color saturated apps stripped of their color are starting to feel like older apps or appliances. Switching Spotify playlists felt a bit like pressing station presets on a car radio. Discord felt like an enhanced IRC client. Even some of my rotating lock screen landscape photos have strong Ansel Adams vibes, while my urban lockscreen photos have a calmer dreamlike quality. Perhaps the use of color in modern mobile app user interfaces is the new chartjunk, extraneous and distracting from the task at hand, just as classic chartjunk is extraneous and distracting from the information being presented. Most mobile apps seem to be in an attention-seeking arms race against each other, ever more saturated colors to draw you in like a casino. Using a grayscale iPhone user interface for most of the day has felt noticeably calmer. Enough for me to try it again for at least a few days and see how it goes. Thanks again to James for his explanations and encouragement. See his write-up: Using greyscale, when he started, why, why he continues to use it, and instructions for his setup. Try it for yourself and see how it feels. May the Force of your will be with you, free of distractions and dopamine conditioned impulses. Further Reading 2018-01-12 The New York Times: Is the Answer to Phone Addiction a Worse Phone? / I’ve gone gray, and it’s great. 2018-05-03 The Observer: Grayscale Is a Quick Cure to Smartphone Addiction—And Here’s How to Use It 2019-12-01 WIRED: Try Grayscale Mode to Curb Your Phone Addiction

Mozilla Data YouTube Channel: Last Lecture: Writing the Data Docs

Tue, 05 May 2026 13:46:43 +0200

Will Lachance gives a last lecture on writing data documentation at Mozilla.

Mozilla Privacy Blog: Mozilla calls on UK policymakers to address the roots of online harm, not undermine the open web

Tue, 05 May 2026 11:32:36 +0200

Mozilla has joined a coalition of 19 digital rights organizations and technology providers in a joint statement, urging UK policymakers not to undermine the open web in their efforts to protect young people online. Our mission is grounded in the belief that the internet must remain open and accessible to all, and that privacy and security online are fundamental. Around the globe, we are witnessing blunt policy interventions like age gates or restrictions on VPNs that put these values at risk. Child safety is a complex and central issue to us all, and as we have said before, Mozilla supports robust, proportionate safeguards for minors. However, we are concerned that mandatory age verification or VPN restrictions undermine online privacy and security, people’s ability to express themselves and access information, and ultimately the health of the web itself. In an attempt to address tough questions surrounding online harms, UK policymakers are currently consulting on which services and features should be placed behind age gates as part of a national consultation on online harms. A broad range of services are being considered for age restrictions, including search engines, games and VPNs. Even targeted age restrictions of certain features would require all users to submit to age assurance systems. However, existing age assurance technologies have been found to either undermine users’ privacy and data security, to be insufficiently accurate or not widely accessible across populations. Age restrictions could also entrench the dominance of gatekeepers and fragment the web into a patchwork of age-gated jurisdictions. Beyond the significant risks associated with mandating age assurance across core internet services, we are particularly concerned about proposals to restrict the use of VPNs. VPNs and similar services are essential privacy and security tools used by millions of users for legitimate purposes. Restricting the use of privacy-preserving technologies undermines efforts to empower users to navigate the web safely and to develop digital literacy. Rather than age-restricting a growing number of services, we believe that addressing the roots of child safety concerns, such as poor content moderation, irresponsible data practices, and deceptive design, is a more proportionate and effective way forward. We thus urge policymakers to prioritize policy interventions that centre children’s’ rights and all users’ agency and choice, and protect, not undermine, the open web. The post Mozilla calls on UK policymakers to address the roots of online harm, not undermine the open web appeared first on Open Policy & Advocacy.

Firefox Tooling Announcements: MozPhab 2.15.0 Released

Tue, 05 May 2026 18:23:33 +0200

Bugs resolved in Moz-Phab 2.15.0: bug 2033810 Open the browser to the uplift request form on successful moz-phab uplift bug 2036007 test_integration_patch.py flaky since v2.14.0 bug 2036394 moz-phab: circleci => github action bug 2036890 Push moz-phab to PyPI using Trusted Publisher workflow Discuss these changes in #engineering-workflow on Slack or #Conduit Matrix. 1 post - 1 participant Read full topic

Firefox Tooling Announcements: New deploy of PerfCompare! May 5th

Tue, 05 May 2026 20:22:09 +0200

The latest version of PerfCompare is now live! Check out the change-log below to see the updates: Highlights [kala] Bug 2032537: Results Page: show count of the improvements and regressions in the subtests per platform Bug 2026346: Created cookies to save previous sort and filter selection Bug 2026353: Sorting CLES by abs value - 0.5 Other contributions: [kala] Added the optional param enable_silverman_kde to loaders and treeherder logic [moijes] Bug-2022758: Remove redundant Dark fonts Thank you for the contributions! Bugs or feature requests can be filed on Bugzilla. The team can also be found on the #perfcompare channel on Element. Come and chat! 1 post - 1 participant Read full topic

Firefox Tooling Announcements: Firefox Profiler Deployment (May 7, 2026)

Thu, 07 May 2026 16:59:02 +0200

The latest version of the Firefox Profiler is now live! Check out the full changelog below to see what’s changed: Highlights: [Markus Stange] Use custom splitter component (#4606) [fatadel] Fix Download button text color when clicked (#5985) [Nazım Can Altınova] Add profiler-cli for querying profiles (#5963) Firefiox Profiler now has a CLI! You can download it here: https://www.npmjs.com/package/@firefox-devtools/profiler-cli [Nazım Can Altınova] Fix the unnecessary stringify of Uint8Array contents during zip profile extraction (#6004) Other Changes: [Samuel Glauser] Fix fullscreen icon size in bottom box (#5987) [Nazım Can Altınova] Bump profiler cli version to 0.1.0 (#5996) [Markus Stange] Switch from max-height to maxHeight in JSX style={{…}}. (#5990) [carverdamien] Fix comment about how time and duration are stored (#5997) [Nazım Can Altınova] Do not show console error when libnames are failed to parse as a URL (#5993) [Nazım Can Altınova] Fix the unnecessary stringify of Uint8Array contents during zip profile extraction (#6004) Big thanks to our amazing localizers for making this release possible: en-CA: chutten en-CA: Saurabh en-GB: Ian Neal es-CL: ravmn fy-NL: Fjoerfoks ia: Melo46 nl: Mark Heijl ru: Valery Ledovskoy sv-SE: Andreas Pettersson Find out more about the Firefox Profiler on profiler.firefox.com! If you have any questions, join the discussion on our Matrix channel! 1 post - 1 participant Read full topic

This Week In Rust: This Week in Rust 650

Wed, 06 May 2026 06:00:00 +0200

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions. This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR. Want TWIR in your inbox? Subscribe here. Updates from Rust Community Official Announcing Google Summer of Code 2026 selected projects Newsletters Rust Trends Issue 77 - Rust Sharpens the Craft Project/Tooling Updates Imgclip: A Cross-Platform CLI for Clipboard ↔ Image File Conversion Connectors: Where AimDB Meets the Real World rkik-nts 1.0.0: a high-level Rust Network Time Security (RFC 8915) client library unix-ancillary 0.2.2 — safe SCM_RIGHTS fd-passing for Rust kache 0.2.0: zero-copy, content-addressed Rust build cache (RUSTC_WRAPPER) Fileman - a cross-platform 2-panel file manager Observations/Thoughts One week of view_types Async Rust never left the MVP state stable specialization in Rust Your Clippy Config Should Be Stricter Your Clippy Config Should Be Stricter-er The Sync bound nobody asked for Cross-platform Rust: Analyzing how WhatsApp, Signal and more are shipping Rust to billions of devices [audio] Netstack.FM episode 37 — dial9: from black box to insight in Tokio Rust Walkthroughs oops, cubic macro! [video] RustCurious lesson 7: Arrays and Slices Writing Middlewares for Rust Lambda Functions Learn Error Handling in Rust By Building a TOML Config Parser Miscellaneous Awesome SQLx Resources Crate of the Week This week's crate is burn, a tensor and deep learning library. Thanks to Jonas for the suggestion! Please submit your suggestions and votes for next week! Calls for Testing An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization. If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing. No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs. Let us know if you would like your feature to be tracked as a part of this list. Call for Participation; projects and speakers CFP - Projects Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started! Some of these tasks may also have mentors available, visit the task page for more information. No Calls for participation were submitted this week. If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon! CFP - Events Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker. Scientific Computing in Rust 2026| 2026-06-05 | Virtual | 2026-07-08 - 2026-07-10 If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon! Updates from the Rust Project 504 pull requests were merged in the last week Compiler canonicalize free regions from inputs as placeholders in root univ Library don't reload length in String::push Cargo feat(lints): Add deny-by-default text_direction_codepoint lints fix(compile): Where possible, hint about misplaced deps fix(config): [env] relative paths definition fix(config): normalize included config paths remove curl dependency from crates-io crate Rustdoc fix doc_cfg feature on reexports preserve parent doc cfg for macro_export macros Clippy add a check for some followed by filter fix bad_bit_mask ICE for overloaded bit ops needless_return_with_question_mark trigger in async functions Rust-Analyzer diagnostics: add handler for E0130 add AssocItemList add_item editor variant expand glob import on cyclic import fail add diagnostic for E0784 allow renaming of elided lifetimes diagnose trait errors 🎉 emit a diagnostic for non_exhaustive struct when constructed offer on if-expr with else-if for convert_to_guarded_return support if-else in value on postfix completions add missing exprs to visiting add missing solver lang items add semicolon after expr in stmt for unwrap_branch catch #[rustc_reservation_impl = "reason"] don't fetch diagnostics until proc-macros are loaded don't panic on impl ?Sized for introduce_named_type_parameter fix unwrap_branch in match_arm fix stack overflow on projection display handle empty expr in tuple expr improve prettify_macro_expansion() improve whitespaces for trait item complete infer the expected type as the return type for async blocks defined by async fns port array and ref exprs inference from rustc qualify .new path and no complete generic params remove usage of references_error() in upvar inference show the user's message for #[must_use] use Pattern_White_Space for whitespace handling various fixes for lower_coroutine_body_with_moved_arguments() wrap top level or patterns in parens in convert_match_to_let_else hir-ty: emit diagnostic for unused #[must_use] values ide-diagnostics: emit error for duplicate field in record expression ide-diagnostics: emit error for mismatched array pattern length migrate generate function to SyntaxEditor perf: cache more things that are related to lang items (paren traits, children/sibling assoc types/functions) but are not lang items themselves perf: do not intern AdtDef perf: improve performance of integer-based symbols remove add predicate for Where syntax remove unused a method in edit_in_place replace insert use and insert use as alias with its editor variant use syntaxFactory in generic arg instead of vanilla make Rust Compiler Performance Triage This week's result is pretty much neutral. It looks negative in icount numbers, but that's spurious, wall time remained largely unchanged. Some big performance improvements landed in the new solver, which is not enabled by default, yet. Triage done by @panstromek. Revision range: ca9a134e..1d72d7e8 Summary: (instructions:u) mean range count Regressions ? (primary) 0.6% [0.2%, 1.2%] 106 Regressions ? (secondary) 0.7% [0.2%, 2.4%] 67 Improvements ? (primary) -0.6% [-1.7%, -0.2%] 66 Improvements ? (secondary) -0.6% [-2.8%, -0.0%] 60 All ?? (primary) 0.1% [-1.7%, 1.2%] 172 1 Regression, 2 Improvements, 9 Mixed; 5 of them in rollups 34 artifact comparisons made in total Full report here Approved RFCs Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: No RFCs were approved this week. Final Comment Period Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. Tracking Issues & PRs Rust Make trait refs & assoc ty paths properly induce trait object lifetime defaults validate #[link_name = "..."] & #[link(name = "...")] parameters Improve precision of Duration-float operations Tracking Issue for unsafe_cell_access Tracking Issue for producing a Result from a bool Allow shortening lifetime in CoerceUnsized for &mut Ensure Send/Sync is not implemented for std::env::Vars{,Os} feat(rustdoc): stabilize --emit flag Make Infallible = ! Add lint againts invalid runtime symbol definitions error on empty export_name Check arguments of attributes where no arguments are expected stabilize feature(cfg_target_has_atomic_equal_alignment) fix: fix the capture behavior of if let in closures Resolver: Batched Import Resolution Ensure Send/Sync impl for std::process::CommandArgs Compiler Team (MCPs only) Turn long-deprecated -C options into errors Promote loongarch32-unknown-none* to Tier 2 Rust RFCs Propose the concept of a crates.io username for identity Language Team Revise decision process: champion vs FCP decisions No Items entered Final Comment Period this week for Cargo, Language Reference, Leadership Council or Unsafe Code Guidelines. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list. New and Updated RFCs Initial Rustdoc LaTeX math RFC Project-wide LLM policy Upcoming Events Rusty Events between 2026-05-06 - 2026-06-03 🦀 Virtual 2026-05-06 | Virtual (Cardiff, UK) | Rust and C++ Cardiff Practical introduction to SIMD 2026-05-06 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-05-06 | Virtual (Indianapolis, IN, US) | Indy Rust Indy.rs - with Social Distancing 2026-05-07 | Virtual (Berlin, DE) | Rust Berlin Rust Hack and Learn 2026-05-07 | Virtual (Nürnberg, DE) | Rust Nuremberg Rust Nürnberg online 2026-05-09 | Virtual (Girona, ES) | Rust Girona Learning Rust the Hard Way: Building a TUI Chess Game 2026-05-12 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Second Tuesday 2026-05-12 | Virtual (London, UK) | Women in Rust 👋 Community Catch Up 2026-05-12 | Virtual (Tel Aviv-yafo, IL) | Code Mavens 🦀 - 🐍 - 🐪 Introduction to database access using Rust SQLx 2026-05-17 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Rust Deep Learning: Third Sunday 2026-05-19 | Virtual (Washington, DC, US) | Rust DC Mid-month Rustful 2026-05-20 | Hybrid (Vancouver, BC, CA) | Vancouver Rust Mouse Control with Rust 2026-05-20 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-05-21 | Hybrid (Seattle, WA, US) | Seattle Rust User Group May, 2026 SRUG (Seattle Rust User Group) Meetup 2026-05-21 | Virtual (Berlin, DE) | Rust Berlin Rust Hack and Learn 2026-05-21 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup Tock OS Part #4 - Capsule coding in QEMU! 2026-05-26 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Fourth Tuesday 2026-05-26 | Virtual (London, UK) | Women in Rust Lunch & Learn: Seeing Into Your Code - A Practical Guide to Tracing in Rust 2026-05-27 | Virtual (Girona, ES) | Rust Girona Weekly coding session 2026-06-03 | Virtual (Indianapolis, IN, US) | Indy Rust Indy.rs - with Social Distancing Africa 2026-05-12 | Johannesburg, ZA | Johannesburg Rust Meetup Rust by Example - Flow of Control Asia 2026-05-13 | Malaysia, MY | Rust Meetup Malaysia Rust Meetup May 2026 2026-05-14 | Seoul, KR | Seoul Rust (Programming Language) Meetup Seoul Rust Meetup 2026-05-16 | Bangalore, IN | Rust Bangalore May 2026 Rustacean meetup Europe 2026-05-06 | Köln, DE | Rust Cologne Rust in May: Rust for Starters, Part 2 2026-05-06 | Milano, MI, IT | Rust Language Milan Rust Milan @ Python Milano: Python or Rust? Yes! 2026-05-06 | Oxford, UK | Oxford ACCU/Rust Meetup. Building LLMs from scratch 2026-05-07 | Edinburgh, UK | Rust and Friends Rust May Talks: Aetherus + Bevy 2026-05-11 | Augsburg, DE | Rust Meetup Augsburg Rust Meetup #19: Tiago Manczak - Game On with Rust & Pico 2026-05-13 | Girona, ES | Rust Girona Rust Girona Hack & Learn 05 2026 2026-05-14 | Switzerland, CH | PostTenebrasLab Rust Meetup Geneva 2026-05-18 - 2026-05-23 | Amsterdam, NL | RustWeek 2026 RustWeek 2026 2026-05-18 | Milano, MI, IT | Rust Language Milan RustWeek 2026 2026-05-19 | Aarhus, DK | Rust Aarhus Hack Night 2026-05-19 | Amsterdam, NL | RustNL RustWeek 2026 announcement 2026-05-19 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig Cross-Building & Cross-Testing 2026-05-19 | London, UK | Women in Rust RustWeek lunch meetup 2026-05-21 | Amsterdam, NL | RustNL RustWeek Hackathon 2026-05-22 | Amsterdam, NL | RustNL Bike tour around Utrecht 2026-05-26 | Dortmund, DE | Rust Dortmund Rust Dortmund Meetup - Agentic Programming - May 2026-05-26 | Manchester, UK | Rust Manchester Rust Manchester May Code Night 2026-05-29 | Berlin, DE | Rust Berlin Rust Berlin Talks: The next generation North America 2026-05-07 | New York, NY, US | Rust NYC Rust NYC: Reversing the Great Firewall and Geospatial Rust 2026-05-07 | Saint Louis, MO, US | STL Rust Open Project Night 2026-05-09 | Boston, MA, US | Boston Rust Meetup Back Bay Rust Lunch, May 9 2026-05-14 | Mountain View, CA, US | Hacker Dojo RUST MEETUP at HACKER DOJO 2026-05-14 | Portland, OR, US | PDXRust From Radio Waves to Pixels - Real-Time Visualizations with Rust and WebAssembly 2026-05-14 | San Diego, CA, US | San Diego Rust San Diego Rust May Meetup - Back in person! 2026-05-16 | Boston, MA, US | Boston Rust Meetup Lechmere Rust Lunch, May 16 2026-05-19 | San Francisco, CA, US | San Francisco Rust Study Group Rust Hacking in Person 2026-05-20 | Hybrid (Vancouver, BC, CA) | Vancouver Rust Mouse Control with Rust 2026-05-20 | San Francisco, CA, US | Bay Area Rust Meetup Bay Area Rust Meetup 2026-05-21 | Hybrid (Seattle, WA, US) | Seattle Rust User Group May, 2026 SRUG (Seattle Rust User Group) Meetup 2026-05-21 | Nashville, TN, US | Music City Rust Developers Community Meetup 2026-05-23 | Boston, MA, US | Boston Rust Meetup Allston Rust Lunch, May 23 2026-05-27 | Austin, TX, US | Rust ATX Rust Lunch - Fareground 2026-05-28 | Atlanta, GA, US | Rust Atlanta Rust-Atl 2026-05-28 | Los Angeles, CA, US | Rust Los Angeles Rust LA: Rust in Embedded & Autonomous Systems at Parallel Systems in DTLA 2026-05-30 | Boston, MA, US | Boston Rust Meetup Central Cambridge Rust Lunch, May 30 Oceania 2026-05-14 | Melbourne, AU | Rust Melbourne Rust Melbourne - May 2026 2026-05-26 | Barton, ACT, AU | Canberra Rust User Group May Meetup South America 2026-05-13 | Montevideo, UY | Rust Meetup Uruguay Rust Uruguay meetup de Mayo If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access. Jobs Please see the latest Who's Hiring thread on r/rust Quote of the Week From a business standpoint, we should have reasonable confidence that it’ll stick around and be healthy for more than 10 years. We’d also like a robust ecosystem of code and tools that we can rely on, and experts we can hire. – David Anderson on the tailscale blog Thanks to Ivan Fraixedes for the suggestion! Please submit quotes and vote for next week! This Week in Rust is edited by: nellshamrell llogiq ericseppanen extrawurst U007D mariannegoldin bdillo opeolluwa bnchi KannanPalani57 tzilist Email list hosting is sponsored by The Rust Foundation Discuss on r/rust

Helfen Sie mit, dass Thunderbird auch im Jahr 2023 noch lebt und gedeiht

Wed, 23 Nov 2022 02:35:06 +0100

Noch vor wenigen Jahren stand Thunderbird kurz vor dem Aussterben. Aber Sie haben uns gerettet! Heute brauchen wir wieder Ihre Hilfe. The post Helfen Sie mit, dass Thunderbird auch im Jahr 2023 noch lebt und gedeiht appeared first on The Thunderbird Blog.

Machen Sie den Thunderbird zu Ihrem: Wie Sie den Thunderbird 115 „Supernova“-Look bekommen

Fri, 11 Aug 2023 06:02:34 +0200

Sind Sie neugierig, wie Sie diesen glänzenden neuen "Supernova"-Look bekommen? Hier finden Sie eine Schritt-für-Schritt-Anleitung zur Aktivierung des vertikalen Layouts, der Kartenansicht und des Tags-Modus in Thunderbird 115. The post Machen Sie den Thunderbird zu Ihrem: Wie Sie den Thunderbird 115 „Supernova“-Look bekommen appeared first on The Thunderbird Blog.

Maximieren Sie Ihren Tag: Zeitblockierung mit Thunderbird

Thu, 30 May 2024 14:39:35 +0200

Lernen Sie die Grundlagen der Zeitplanung mit dem Thunderbird-Kalender, damit Sie Ihre kostbare Ressource optimal nutzen können: Ihre Zeit! The post Maximieren Sie Ihren Tag: Zeitblockierung mit Thunderbird appeared first on The Thunderbird Blog.

Thunderbird: Der Build- und Release-Prozess erklärt

Mon, 10 Jun 2024 12:00:00 +0200

VIDEO: Wayne und Daniel beleuchten den Entwicklungs- und Veröffentlichungsprozess von Thunderbird, halten eine informative Präsentation und führen uns durch eine Live-Demo. The post Thunderbird: Der Build- und Release-Prozess erklärt appeared first on The Thunderbird Blog.

Maximieren Sie Ihren Tag: Behandeln Sie Ihre E-Mails wie Wäsche

Thu, 20 Jun 2024 15:52:11 +0200

Ertrinken Sie in E-Mails? Gewinnen Sie Ihre wertvolle Zeit zurück und verwandeln Sie Ihren Posteingang mit diesem erfrischenden Tipp zur E-Mail-Verwaltung in ein Kraftwerk der Produktivität! The post Maximieren Sie Ihren Tag: Behandeln Sie Ihre E-Mails wie Wäsche appeared first on The Thunderbird Blog.

Willkommen bei Thunderbird 128 „Nebula“

Fri, 12 Jul 2024 14:11:17 +0200

Im Weltraum erzeugt eine Supernova die Bausteine der Schöpfung. In einem Nebel nähren diese Elemente neue Möglichkeiten. Thunderbird 128 Nebula vereint das Beste aus Supernova! und baut darauf auf. Finden Sie heraus, was in unserer ersten Version 2024 neu ist. The post Willkommen bei Thunderbird 128 „Nebula“ appeared first on The Thunderbird Blog.

Thunderbird und Spam

Tue, 17 Sep 2024 12:00:00 +0200

Der Umgang mit Spam in unserer täglichen E-Mail-Routine kann frustrierend sein, aber Thunderbird verfügt über einige Tools, die unerwünschte Nachrichten weniger lästig machen. Es braucht Zeit, Training und Geduld, aber schließlich können Sie können den Kampf gegen Junk-Mails gewinnen. In diesem Artikel erklären wir Ihnen, wie der Spam-Filter von Thunderbird funktioniert und wie Sie ihn […] The post Thunderbird und Spam appeared first on The Thunderbird Blog.

Thunderbird Monthly Development Digest – February 2025

Tue, 11 Mar 2025 15:32:28 +0100

Hello again Thunderbird Community! Despite the winter seeming to last forever and the world being in a state of flux, the Thunderbird team has been hard at work both in development and planning strategic projects. Here’s the latest from the team dedicated to making Thunderbird better each day: Monthly Releases are here! The concept of […] The post Thunderbird Monthly Development Digest – February 2025 appeared first on The Thunderbird Blog.

VIDEO: The Thunderbird Design System

Thu, 13 Mar 2025 20:07:23 +0100

In this month’s Community Office Hours, Laurel Terlesky, Design Manager, is talking about the new Thunderbird Design System. In her talk from FOSDEM, “Building a Cross-Platform, Scalable, Open-Source Design System,” Laurel describes the Thunderbird design journey. If you are interested in how the desktop and mobile apps have gotten their new look, or in the […] The post VIDEO: The Thunderbird Design System appeared first on The Thunderbird Blog.

Thundermail and Thunderbird Pro Services

Fri, 04 Apr 2025 18:58:00 +0200

Today we’re pleased to announce what many in our open source contributor community already know. The Thunderbird team is working on an email service called “Thundermail” as well as file sharing, calendar scheduling and other helpful cloud-based services that as a bundle we have been calling “Thunderbird Pro.” First, a point of clarification: Thunderbird, the […] The post Thundermail and Thunderbird Pro Services appeared first on The Thunderbird Blog.

Thunderbird Monthly Development Digest – March 2025

Tue, 08 Apr 2025 15:31:42 +0200

Hello again Thunderbird Community! It’s been almost a year since I joined the project and I’ve recently been enjoying the most rewarding and exciting work days in recent memory. The team who works on making Thunderbird better each day is so passionate about their work and truly dedicated to solving problems for users and supporting […] The post Thunderbird Monthly Development Digest – March 2025 appeared first on The Thunderbird Blog.

Thunderbird for Android March 2025 Progress Report

Thu, 10 Apr 2025 18:06:52 +0200

Hello, everyone, and welcome to the Thunderbird for Android March 2025 Progress Report. We’re keeping our community updated on everything that’s been happening in the Android team, which is quickly becoming a more general mobile team with some recent hires. In addition to team news, we’re talking about our roadmap board on GitHub. Team Changes […] The post Thunderbird for Android March 2025 Progress Report appeared first on The Thunderbird Blog.

VIDEO: The New Account Hub

Fri, 11 Apr 2025 14:18:36 +0200

In this month’s Community Office Hours, we’re chatting with Vineet Deo, a Software Engineer on the Desktop team, who walks us through the new Account Hub on the Desktop app. If you want a sneak peak at this new streamlined experience, you can find it in the Daily channel now and the Beta channel towards […] The post VIDEO: The New Account Hub appeared first on The Thunderbird Blog.

Thunderbird Monthly Developer Digest – April 2025

Tue, 13 May 2025 15:25:11 +0200

Hello from the Thunderbird development team! With some of our time spent onboarding new team members and interviewing for open positions, April was a fun and productive month. Our team grew and we were amazed at how smooth the onboarding process has been, with many contributions already boosting the team’s output. Gearing up for our […] The post Thunderbird Monthly Developer Digest – April 2025 appeared first on The Thunderbird Blog.

Thunderbird for Mobile April 2025 Progress Report

Thu, 15 May 2025 16:26:15 +0200

Here is an update of what Thunderbird’s mobile community has been up to in April 2025. With a new team member, we’re getting Thunderbird for iOS out in the open and continuing to work on release feedback from Thunderbird for Android. The Team is Growing Last month we introduced Todd and Ashley to the MZLA […] The post Thunderbird for Mobile April 2025 Progress Report appeared first on The Thunderbird Blog.

VIDEO: Talking MZLA with Ryan Sipes

Tue, 20 May 2025 15:05:37 +0200

In this month’s Community Office Hours, we’re chatting with our director Ryan Sipes. This talk opens with a brief history of Thunderbird and ends on our plans for its future. In between, we explain more about MZLA and its structure, and how this compares to the Mozilla Foundation and Corporation. We’ll also cover the new […] The post VIDEO: Talking MZLA with Ryan Sipes appeared first on The Thunderbird Blog.

VIDEO: Thunderbird Pro and Thundermail!

Wed, 04 Jun 2025 15:26:16 +0200

It’s been just over two months (!) since we first announced our upcoming Thunderbird Pro suite and Thundermail email service. We thought it would be a great idea to bring in Chris Aquino, a Software Engineer on our Services team, to chat about these upcoming products. We want our community to get to know the […] The post VIDEO: Thunderbird Pro and Thundermail! appeared first on The Thunderbird Blog.

Thunderbird Mobile Progress Report: May 2025

Fri, 20 Jun 2025 16:47:06 +0200

Thunderbird for iOS We’re growing a few more stars! We’re so happy to hear there is great interest in Thunderbird for iOS, and hope to reach a stage soon where you all can be more involved. Thank you, also, to those of you who’ve submitted an increasing number of ideas via Mozilla Connect. Todd has […] The post Thunderbird Mobile Progress Report: May 2025 appeared first on The Thunderbird Blog.

Welcome to Thunderbird 140 “Eclipse”

Mon, 07 Jul 2025 19:18:33 +0200

The wait is over! Thunderbird 140 “Eclipse” has reached totality. From all of us at the Thunderbird project, from MZLA staff and the Thunderbird Council to our global community of contributors, we’re excited to announce the latest Extended Support Release has arrived. Eclipse not only builds on Thunderbird 128 “Nebula,” but also the recent features […] The post Welcome to Thunderbird 140 “Eclipse” appeared first on The Thunderbird Blog.

Thunderbird Monthly Development Digest – June 2025

Wed, 09 Jul 2025 17:07:38 +0200

Hello once more from the Thunderbird development team! For many of our team members, the summer has started with our annual sprint to release ESR and enjoy a little time afk, as our colleagues in the southern hemisphere hunker down for winter and power through a pile of work down under. Extended Support Release is […] The post Thunderbird Monthly Development Digest – June 2025 appeared first on The Thunderbird Blog.

Mobile Progress Report – June 2025

Mon, 14 Jul 2025 16:33:06 +0200

Welcome back to another update on how things are going on mobile. Thunderbird for iOS We’ve been going back and forth between database and JMAP for Thunderbird for iOS. Most of the visible work has flown into creating an initial JMAP library that we can use to access the parts that we need from Thunderbird […] The post Mobile Progress Report – June 2025 appeared first on The Thunderbird Blog.

VIDEO: Thunderbird 140.0 ESR “Eclipse”

Fri, 25 Jul 2025 20:53:27 +0200

Welcome back to another edition of the Community Office Hours! This month, we’re taking a closer look at Thunderbird 140.0 ESR “Eclipse,” our latest Extended Support Release! Sr. Manager of Desktop Engineering Toby Pilling (who so helpfully provides the Thunderbird Monthly Development Digest) is walking us through the latest Thunderbird. He’ll let us know what’s […] The post VIDEO: Thunderbird 140.0 ESR “Eclipse” appeared first on The Thunderbird Blog.

Welcoming New Faces to the Thunderbird Community Team

Tue, 29 Jul 2025 15:24:08 +0200

Community First Thunderbird is (and has always been) powered by the people. The project exists because of the amazing community of passionate code contributors, bug-bashers, content creators, and all-around wonderful humans who have stood behind it and worked to support and maintain it over the years. And as the Thunderbird community grows, we want to […] The post Welcoming New Faces to the Thunderbird Community Team appeared first on The Thunderbird Blog.

State of the Thunder: Answering Community Questions!

Wed, 30 Jul 2025 17:50:37 +0200

For the past few months, we’ve been talking about our roadmaps and development and answering community questions in a video and podcast series we call “State of the Thunder.” We’ve decided, after your feedback, to also cover them in a blog, for those who don’t have time to watch or listen to the entire session. […] The post State of the Thunder: Answering Community Questions! appeared first on The Thunderbird Blog.

Monthly Release 141 Recap

Fri, 01 Aug 2025 16:00:00 +0200

We’re launching a brand new series that will highlight features and improvements with Thunderbird 141.0 – your front row ticket to Thunderbird’s monthly enhancements! (No more waiting in the wings so to speak). Learn what’s new, why it matters, and how it’ll transform your inbox experience. In March, we introduced a new monthly Release channel […] The post Monthly Release 141 Recap appeared first on The Thunderbird Blog.

Engage Your Inbox with ‘Getting Things Done’

Wed, 06 Aug 2025 17:07:16 +0200

David Allen’s “Getting Thing Done” (GTD) system has been around for longer than Thunderbird! First published in a book of the same name in 2001, this approach to productivity is focused on freeing your brain from chaos, giving it “focus, clarity, and confidence” for creativity and new ideas. As I’m also a fan of freedom […] The post Engage Your Inbox with ‘Getting Things Done’ appeared first on The Thunderbird Blog.

Thunderbird Monthly Development Digest – July 2025

Thu, 14 Aug 2025 16:40:02 +0200

Hello again from the Thunderbird development team! As the northern hemisphere rolls into late summer and the last of the vacation photos trickle into our chat channels, the team is balancing maintenance sprints with ongoing feature-related projects. Whether you’re basking in the sun or bundled up for a southern winter, we’ve got plenty to share […] The post Thunderbird Monthly Development Digest – July 2025 appeared first on The Thunderbird Blog.

Thunderbird Pro August 2025 Update

Tue, 19 Aug 2025 20:54:37 +0200

In April of this year we announced Thunderbird Pro, additional subscription services from Thunderbird meant to help you get more done with the app you already use and love. These services include a first ever email service from Thunderbird, called Thundermail. They also include Appointment, for scheduling meetings and appointments and Send, an end-to-end encrypted […] The post Thunderbird Pro August 2025 Update appeared first on The Thunderbird Blog.

Thunderbird Monthly Release 142 Recap

Thu, 28 Aug 2025 15:43:54 +0200

We’re back with another exciting Monthly Release recap! Thunderbird 142.0 brings a host of user-requested features and important bug fixes that make your email experience smoother and more reliable. From better folder management to smarter PDF handling, this release focuses on the details that matter most to your daily workflow. A quick reminder – these […] The post Thunderbird Monthly Release 142 Recap appeared first on The Thunderbird Blog.

VIDEO: Thunderbird Accessibility Study

Fri, 05 Sep 2025 17:14:54 +0200

Welcome back to another edition of the Community Office Hours! This month, we’re taking a closer look at accessibility in the Thunderbird desktop and mobile apps. We’re chatting with Rebecca Taylor and Solange Valverde, members of our designer, about a recent accessibility (often shortened as a11y) study. We wanted to find out where Thunderbird was […] The post VIDEO: Thunderbird Accessibility Study appeared first on The Thunderbird Blog.

State of the Thunder: Mozilla Connect Updates

Thu, 11 Sep 2025 21:20:10 +0200

Welcome back to the latest season of State of the Thunder! After a short break, we’re back and ready to go. Michael Ellis, our Manager of Community Programs, is helping Alessandro with hosting duties. Along with members of the Thunderbird team and community, they’re answering your questions and keeping everyone updated on our roadmap progress […] The post State of the Thunder: Mozilla Connect Updates appeared first on The Thunderbird Blog.

Mobile Progress Report – July/August 2025

Mon, 15 Sep 2025 17:09:31 +0200

Hello wonderful community, it has been a while since the last Mobile update. A lot has happened in the past 2 months, so let’s jump right into a quick overview of current work in progress and primary efforts. Account Drawer in progress If you’re rocking the Beta version of Thunderbird for Android, you might have […] The post Mobile Progress Report – July/August 2025 appeared first on The Thunderbird Blog.

State of the Thunder 12: Community, Android, and Mozilla Connect

Tue, 23 Sep 2025 17:10:45 +0200

We’re back with our twelfth episode of the State of the Thunder! In this episode, we’re talking about community initiatives, filling you in on Android development, and finishing our updates on popular Mozilla Connect requests. Want to find out how to join future State of the Thunders? Be sure to join our Thunderbird planning mailing […] The post State of the Thunder 12: Community, Android, and Mozilla Connect appeared first on The Thunderbird Blog.

Thunderbird Monthly Development Digest: August 2025

Wed, 24 Sep 2025 16:22:05 +0200

Hello again from the Thunderbird development team! As autumn settles in, we’re balancing the steady pace of ongoing projects with some forward-looking planning for 2026. Alongside coding and testing, some of our recent attention has gone into budgets, roadmaps, and setting priorities for the year ahead. It’s not the most glamorous work, but it’s essential […] The post Thunderbird Monthly Development Digest: August 2025 appeared first on The Thunderbird Blog.

VIDEO: Conversation View

Mon, 06 Oct 2025 20:08:18 +0200

Welcome back to another edition of the Community Office Hours! This month, we’re showing you our first steps towards a long awaited feature: a genuine Conversation View! Our guests are Alessandro Castellani, Director of Desktop and Mobile Apps and Geoff Lankow, Sr. Staff Software Engineer on the Desktop team. They recently attended a work week […] The post VIDEO: Conversation View appeared first on The Thunderbird Blog.

State Of The Bird 2024/25

Wed, 08 Oct 2025 12:02:00 +0200

The past twelve months have been another remarkable chapter in Thunderbird’s journey. Together, we started expanding Thunderbird beyond its strong desktop roots, introducing it to smartphones and web browsers to make it more accessible to more people. Thunderbird for Android arrived in the fall and has been steadily improving thanks to our growing mobile team, […] The post State Of The Bird 2024/25 appeared first on The Thunderbird Blog.

State of the Thunder 13: How We Make Our Roadmap

Fri, 10 Oct 2025 20:37:37 +0200

Welcome back to our thirteenth episode of State of the Thunder! Nothing unlucky about this latest installment, as Managing Director Ryan Sipes walks us through how Thunderbird creates its roadmap. Unlike other companies where roadmaps are driven solely by business needs, Thunderbird is working with our community governance and feedback from the wider user community […] The post State of the Thunder 13: How We Make Our Roadmap appeared first on The Thunderbird Blog.

Thunderbird Monthly Development Digest: September 2025

Fri, 17 Oct 2025 18:35:31 +0200

Hello again from the Thunderbird development team! This month’s sprints have been about focus and follow-through, as we’ve tightened up our new Account Hub experience and continued the deep work on Exchange Web Services (EWS) support. While those two areas have taken centre stage, we’ve also been busy adapting to a wave of upstream platform […] The post Thunderbird Monthly Development Digest: September 2025 appeared first on The Thunderbird Blog.

Your Workflow, Supercharged

Fri, 24 Oct 2025 22:00:11 +0200

Extensions make Thunderbird truly yours, moving at your pace and reflecting your priorities. Thunderbird’s flexibility means you can tailor the app to how you actually work. We’ll cover tools for efficiency, consistency, and visibility so every send is faster and better informed, your future self will thank you. Clippings We’ve all been there, retyping the […] The post Your Workflow, Supercharged appeared first on The Thunderbird Blog.

Mobile Progress Report: September-October 2025

Tue, 28 Oct 2025 21:17:45 +0100

A Brief Self-Introduction Hello community, it’s a pleasure to be here and help take part in a product I’ve used for many years, but now with the focus on Mobile. I am Jon Bott, and am the new Engineering Manager for the Thunderbird Mobile teams. I am passionate about native mobile development and am excited […] The post Mobile Progress Report: September-October 2025 appeared first on The Thunderbird Blog.