Loading today’s stories
Build1 distinct publisher3 min readPublished
The per-tab figures were summed off an unfiltered ps listing, so a browser policy that looked 198 MB ahead was really 91 MB behind. What caught it was watching one number fail to move across a page load.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
build
canvas.toBlob hands you a PNG and calls it WebP: check blob.type, not the user agent1 distinct publisher
build
WebKit rewrites Safari's module loader to make top-level await spec-compliant1 distinct publisher
security
Thousands of credentials survived five years of pentests inside Jira ticket comments1 distinct publisher
build
A cost monitor overcounted 4.9x, then went dark for a week when set -e did its job1 distinct publisher
A test asserts on a value at one moment. The fault here produced a value that looked right at every moment and never changed, and every test written against it passed because the tests asked the browser what it thought rather than checking the browser against the machine [12]. No single assertion or screenshot holds two moments, which is why the discovery came from a screen recording of the same figure sitting unchanged before and after an entirely different page loaded [5][6].
The underlying bug had three distinct causes, each one concealing the next [7]. `ps` lists every WebContent process on the machine, and they are XPC services parented to launchd with identical command lines, so there is no parent and no client tag to filter on; a Safari process or an Electron app someone left open was a valid candidate [8]. Tab creation then picked `.first` on an unordered set, while WebKit spawned five content processes at once on a measured launch, and whichever pid it grabbed was the tab's number for the rest of the tab's life [10]. If exactly one of those five belongs to the new tab, the pick is right one time in five [9]. Meanwhile "cannot measure" rendered as `0 MB`, identical to "costs nothing", so a live page the browser had lost track of counted as free in the total and never became a candidate for demotion [11].
The published pair read as 198.2 MB in the ladder's favour [1][1]. The re-measured pair reads as 90.6 MB against it [2][2]. That is a 288.8 MB swing, and the same run is now over budget in 85% of samples [3][2]. One page gives the scale of a single error: 52 MB reported against 511 MB actually held, understated by 459 MB, a factor of roughly ten [4][4]. A benchmark that only fails inside a believable range will pass review indefinitely.
The per-event lines show where the bias sits [19]. With no policy at event 12, attributed 1049 MB against measured 1089 MB, a 40 MB shortfall [5]. With Kestrel at event 12, 428 MB against 668 MB, a 240 MB shortfall, six times the no-policy gap [6][8]. At event 36 the attributed 749 MB sits inside the 800 MB budget while the measured 989 MB is 189 MB over it [7][15]. Attribution captures effectively all of the memory when nothing is demoted, because every process still belongs to a live tab [20].
The repair is the right shape. The benchmark now reports the attributed sum next to every WebContent process younger than the run, summed, and that second figure needs no attribution at all [14]. Age is the one sound discriminator available, since a process older than the browser cannot belong to it [9]. With every tab live, the two methods agree to within 1 MB [16], and that agreement is what licenses the harder claim: the 25 to 32% gap under the demoting policies is real memory in processes that outlived their tabs, roughly none of it mis-attribution [17]. Demotion releases the web view, but WebKit hangs onto the underlying process, a process that nobody was counting [18].
For that 25 to 32% to mean anything on your stack, two things have to hold: your content processes must survive the view that released them, and you must have a run boundary you can date processes against [17][9]. The author had recorded this failure mode once already, when earlier work improved what `about:memory` reported while returning nothing to the OS, then built a benchmark of the identical shape and missed it for eight months [13]. His conclusion is the transferable part: he had written the lesson down once before but hadn't yet internalized it [13].
Ranked by verification strength, evidence, and original report placement.
In an earlier post, the author reported that Kestrel's memory ladder held 121.7 MB against an unmanaged browser's 319.9 MB on a set of real websites, and that it never went over its budget.
Re-measured, the same run holds 345.9 MB against an unmanaged 255.3 MB, and is over budget in 85% of samples.
The author states the design did not break, the instrument did; on that workload the ladder did harm, and the published figures reported it as the best result in the post.
Kestrel reported a Jira board as costing 52 MB while the process rendering that page held 511 MB; the 52 MB belonged to a completely different application's WebContent process that had been running for eight days.
The author did not catch the fault with a test; he caught it with a screen recording, watching the same figure sit unchanged before and after loading an entirely different page.
The author describes that as a temporal observation, and says no single assertion or screenshot contains one: you have to see two moments next to each other and notice they agree when they should not.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · September 2, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
First-party, unusually legible
Everything rests on one dev.to post by the project's own author, which is the weakness. The strength is that it shows its work: named process ids and counts, three raw per-event lines, budget and event parameters, and a calibration row where the two measurement methods agree to within 1 MB. The arithmetic holds when you redo it — 319.9 minus 121.7, 511 minus 52, 1089 minus 1049 — and the corrected run repeats three times with stable ratios. What is missing is anyone outside the repository confirming a single number.
Nothing to measure yet
Our coverage contains benchmark runs, not users. Nobody outside the project is reported to run Kestrel, depend on its scheduler, or have adopted the attribution-free footprint measure elsewhere, and we decline to read the author's own harness invocations as uptake.
Corrects against its own interest
The rhetoric here runs the wrong way for hype: a headline result is withdrawn, the replacement shows the policy losing to doing nothing, and the "0% over budget" line is replaced with 48% and 62%. If anything the piece undersells its most general finding — that an error correlated with the treatment manufactures the result — by filing it as one developer's eight-month mistake. The one place the writing outruns what is shown is the clean split of the 25–32% gap into orphaned processes and "roughly 0%" mis-attribution, which leans on a single fully-live row.
Reputational, pointing the unusual direction
A personal developer blog post carries the usual reputational upside, and the line that the correction is worth more than the original finding does convert a retraction into publishable material. Set against that: the author names his own project, quantifies how badly he flattered it, and admits he had already written this exact lesson down once and shipped it again eight months later. Incentive pressure exists but is pushing away from the claims made, not toward them.
One voice, arithmetic that checks
We are confident about what happened inside this benchmark and much less confident about anything beyond it. Internal consistency is high — the derived shortfalls, ratios and budget breaches all reproduce from the figures given — but there is a single publisher, a single author, no external replication, and no visibility into how many of the earlier post's other numbers were reading a foreign process. The corrected instrument is asserted to be unfailable by construction; that argument is plausible and untested by a second party.