Simon Willison’s Weblog

Behind the Scenes Hardening Firefox with Claude Mythos Preview (via) Fascinating, in-depth details on how Mozilla used their access to the Claude Mythos preview to locate and then fix hundreds of vulnerabilities in Firefox:

Suddenly, the bugs are very good

Just a few months ago, AI-generated security bug reports to open source projects were mostly known for being unwanted slop. Dealing with reports that look plausibly correct but are wrong imposes an asymmetric cost on project maintainers: it’s cheap and easy to prompt an LLM to find a “problem” in code, but slow and expensive to respond to it.

It is difficult to overstate how much this dynamic changed for us over a few short months. This was due to a combination of two main factors. First, the models got a lot more capable. Second, we dramatically improved our techniques for harnessing these models — steering them, scaling them, and stacking them to generate large amounts of signal and filter out the noise.

They include some detailed bug descriptions too, including a 20-year old XSLT bug and a 15-year-old bug in the <legend> element.

A lot of the attempts made by the harness were blocked by Firefox's existing defense-in-depth measures, which is reassuring.

Mozilla were fixing around 20-30 security bugs in Firefox per month through 2025. That jumped to 423 in April.

# 7th May 2026, 5:56 pm / firefox, mozilla, security, ai, generative-ai, llms, anthropic, claude, ai-security-research

firefox parser/html/java/README.txt (via) TIL (or TIR - Today I was Reminded) that the HTML5 Parser used by Firefox is maintained as Java code (commit history here) and converted to C++ using a custom translation script.

You can see that in action by checking out the ~8GB Firefox repository and running:

cd parser/html/java
make sync
make translate

Here's a terminal session where I did that, including the output of git diff showing the updated C++ files.

I did some digging and found that the code that does the translation work lives, weirdly, in the Nu Html Checker repository on GitHub which powers the W3C's validator.w3.org/nu/ validation service!

Here's a snippet from htmlparser/cpptranslate/CppVisitor.java showing how a class declaration is converted into C++:

    protected void startClassDeclaration() {
        printer.print("#define ");
        printer.print(className);
        printer.printLn("_cpp__");
        printer.printLn();

        for (int i = 0; i < Main.H_LIST.length; i++) {
            String klazz = Main.H_LIST[i];
            if (!klazz.equals(javaClassName)) {
                printer.print("#include \"");
                printer.print(cppTypes.classPrefix());
                printer.print(klazz);
                printer.printLn(".h\"");
            }
        }

        printer.printLn();
        printer.print("#include \"");
        printer.print(className);
        printer.printLn(".h\"");
        printer.printLn();
    }

Here's a fascinating blog post from John Resig explaining how validator author Henri Sivonen introduced the new parser into Firefox in 2009.

# 17th December 2025, 1:48 am / c-plus-plus, firefox, firefox2, henri-sivonen, java, john-resig, mozilla

Shipping WebGPU on Windows in Firefox 141 (via) WebGPU is coming to Mac and Linux soon as well:

Although Firefox 141 enables WebGPU only on Windows, we plan to ship WebGPU on Mac and Linux in the coming months, and finally on Android.

From this article I learned that it's already available in Firefox Nightly:

Note that WebGPU has been available in Firefox Nightly on all platforms other than Android for quite some time.

I tried the most recent Nightly on my Mac and now the Github Issue Generator running locally w/ SmolLM2 & WebGPU demo (previously) works! Firefox stable gives me an error message saying "Error: WebGPU is not supported in your current environment, but it is necessary to run the WebLLM engine."

The Firefox implementation is based on wgpu, an open source Rust WebGPU library.

# 16th July 2025, 1:51 pm / browsers, firefox, mozilla, rust, webgpu

Default styles for h1 elements are changing (via) Wow, this is a rare occurrence! Firefox are rolling out a change to the default user-agent stylesheet for nested <h1> elements, currently ramping from 5% to 50% of users and with full roll-out planned for Firefox 140 in June 2025. Chrome is showing deprecation warnings and Safari are expected to follow suit in the future.

What's changing? The default sizes of <h1> elements that are nested inside <article>, <aside>, <nav> and <section>.

These are the default styles being removed:

/* where x is :is(article, aside, nav, section) */
x h1 { margin-block: 0.83em; font-size: 1.50em; }
x x h1 { margin-block: 1.00em; font-size: 1.17em; }
x x x h1 { margin-block: 1.33em; font-size: 1.00em; }
x x x x h1 { margin-block: 1.67em; font-size: 0.83em; }
x x x x x h1 { margin-block: 2.33em; font-size: 0.67em; }

The short version is that, many years ago, the HTML spec introduced the idea that an <h1> within a nested section should have the same meaning (and hence visual styling) as an <h2>. This never really took off and wasn't reflected by the accessibility tree, and was removed from the HTML spec in 2022. The browsers are now trying to cleanup the legacy default styles.

This advice from that post sounds sensible to me:

• Do not rely on default browser styles for conveying a heading hierarchy. Explicitly define your document hierarchy using <h2> for second-level headings, <h3> for third-level, etc.
• Always define your own font-size and margin for <h1> elements.

# 11th April 2025, 3:54 am / browsers, chrome, css, firefox, html, mozilla, safari, web-standards

Backstory on the default styles for the HTML dialog modal. My TIL about Styling an HTML dialog modal to take the full height of the viewport (here's the interactive demo) showed up on Hacker News this morning, and attracted this fascinating comment from Chromium engineer Ian Kilpatrick.

There's quite a bit of history here, but the abbreviated version is that the dialog element was originally added as a replacement for window.alert(), and there were a libraries polyfilling dialog and being surprisingly widely used.

The mechanism which dialog was originally positioned was relatively complex, and slightly hacky (magic values for the insets).

Changing the behaviour basically meant that we had to add "overflow:auto", and some form of "max-height"/"max-width" to ensure that the content within the dialog was actually reachable.

The better solution to this was to add "max-height:stretch", "max-width:stretch". You can see the discussion for this here.

The problem is that no browser had (and still has) shipped the "stretch" keyword. (Blink likely will "soon")

However this was pushed back against as this had to go in a specification - and nobody implemented it ("-webit-fill-available" would have been an acceptable substitute in Blink but other browsers didn't have this working the same yet).

Hence the calc() variant. (Primarily because of "box-sizing:content-box" being the default, and pre-existing border/padding styles on dialog that we didn't want to touch). [...]

I particularly enjoyed this insight into the challenges of evolving the standards that underlie the web, even for something this small:

One thing to keep in mind is that any changes that changes web behaviour is under some time pressure. If you leave something too long, sites will start relying on the previous behaviour - so it would have been arguably worse not to have done anything.

Also from the comments I learned that Firefox DevTools can show you user-agent styles, but that option is turned off by default - notes on that here. Once I turned this option on I saw references to an html.css stylesheet, so I dug around and found that in the Firefox source code. Here's the commit history for that file on the official GitHub mirror, which provides a detailed history of how Firefox default HTML styles have evolved with the standards over time.

And via uallo here are the same default HTML styles for other browsers:

• Chromium: third_party/blink/renderer/core/html/resources/html.css
• WebKit: Source/WebCore/css/html.css

# 16th March 2025, 4:36 pm / chrome, css, firefox, html, web-standards

MDN Browser Support Timelines. I complained on Hacker News today that I wished the MDN browser compatibility ables - like this one for the Web Locks API - included an indication as to when each browser was released rather than just the browser numbers.

It turns out they do! If you click on each browser version in turn you can see an expanded area showing the browser release date:

There's even an inline help tip telling you about the feature, which I've been studiously ignoring for years.

I want to see all the information at once without having to click through each browser. I had a poke around in the Firefox network tab and found https://bcd.developer.mozilla.org/bcd/api/v0/current/api.Lock.json - a JSON document containing browser support details (with release dates) for that API... and it was served using access-control-allow-origin: * which means I can hit it from my own little client-side applications.

I decided to build something with an autocomplete drop-down interface for selecting the API. That meant I'd need a list of all of the available APIs, and I used GitHub code search to find that in the mdn/browser-compat-data repository, in the api/ directory.

I needed the list of files in that directory for my autocomplete. Since there are just over 1,000 of those the regular GitHub contents API won't return them all, so I switched to the tree API instead.

Here's the finished tool - source code here:

95% of the code was written by LLMs, but I did a whole lot of assembly and iterating to get it to the finished state. Three of the transcripts for that:

• Web Locks API Browser Support Timeline in which I paste in the original API JSON and ask it to come up with a timeline visualization for it.
• Enhancing API Feature Display with URL Hash where I dumped in a more complex JSON example to get it to show multiple APIs on the same page, and also had it add #fragment bookmarking to the tool
• Fetch GitHub API Data Hierarchy where I got it to write me an async JavaScript function for fetching a directory listing from that tree API.

# 11th November 2024, 3:27 am / firefox, github, javascript, mozilla, projects, ai, llms, ai-assisted-programming, claude-3-5-sonnet

Experimenting with local alt text generation in Firefox Nightly (via) The PDF editor in Firefox (confession: I did not know Firefox ships with a PDF editor) is getting an experimental feature that can help suggest alt text for images for the human editor to then adapt and improve on.

This is a great application of AI, made all the more interesting here because Firefox will run a local model on-device for this, using a custom trained model they describe as "our 182M parameters model using a Distilled version of GPT-2 alongside a Vision Transformer (ViT) image encoder".

The model uses WebAssembly with ONNX running in Transfomers.js, and will be downloaded the first time the feature is put to use.

# 2nd June 2024, 1:12 pm / accessibility, alt-text, firefox, javascript, mozilla, pdf, ai, webassembly, llms, transformers-js

New developer features in Firefox 75 (via) Firefox 75 just came out with a bunch of new developer features. My favourite is instant evaluation in the JavaScript console: any statement without side effects now shows a preview of its results as you type.

# 7th April 2020, 7:23 pm / firefox, javascript

selenium-demoscraper (via) Really useful minimal example of a Binder project. Click the button to launch a Jupyter notebook in Binder that can take screenshots of URLs using Selenium-controlled headless Firefox. The binder/ folder uses an apt.txt file to install Firefox, requirements.txt to get some Python dependencies and a postBuild Python script to download the Gecko Selenium driver.

# 4th November 2019, 3:05 pm / firefox, selenium, tony-hirst, jupyter

Boiling the Ocean, Incrementally—How Stylo Brought Rust and Servo to Firefox. Firefox Quantum is the product of an impressive, highly risky chain of software engineering—Rust, Servo, then Stylo.

# 28th November 2017, 8:34 pm / firefox, rust, servo

Firefox Debugger Playground. Excellent hands-on tutorial to using the Firefox JavaScript debugger. I learned a bunch of neat tricks from this—including using conditional breakpoints to add temporary console.log statements—since that function returns undefined it won’t pause your code, but this saves you from having to remember to remove the lines from your source code later. I also didn’t know that the Firefox debugger can show the value of variables in paused code if you hover over them in the source pane. [UPDATE: Turns out Chrome DevTools do this as well—TIL]

# 28th November 2017, 4:01 pm / debuggers, firefox, javascript

Verified cryptography for Firefox 57 (via) Mozilla just became the first browser vendor to ship a formally verified crypto implementation.

# 16th November 2017, 2:26 pm / cryptography, firefox, mozilla

Entering the Quantum Era—How Firefox got fast again and where it’s going to get faster. I’ve been trying out the beta of Firefox 57 and it’s fantastic. All of that work on Servo and Rust is definitely paying off!

# 13th November 2017, 4:34 pm / firefox, rust, servo

Saying Goodbye to Firebug. Firebug has reached end-of-life as a separate extension, replaced by the built-in Firefox Developer Tools. It’s hard to overstate how influential Firebug has been in helping to turn front-end web development into a respected and productive engineering discipline.

# 24th October 2017, 10:38 pm / firebug, firefox

Subresource Integrity. Now supported in Firefox 55, Chrome 49+ and Safari 11+. This makes me much more comfortable about hot-linking to JavaScript and CSS hosted by the various CDN providers, since it means that should they get breached any evil new scripts hosted at the same URL will be denied by modern browsers.

# 18th October 2017, 9:03 pm / firefox, sri

Firefox 4: the HTML5 parser—inline SVG, speed and more. A complete replacement for the oldest part of Gecko (the HTML parser dates back to 1998) headed up by HTML5 validator author Henri Sivonen, using the parsing algorithm defined in the HTML5 specification. Improvements include parsing taking place off the main UI thread and the ability to embed SVG and MathML directly inline in HTML pages.

# 12th May 2010, 8:56 am / firefox, gecko, henri-sivonen, html5, mathml, svg, recovered, firefox4, parser

Plugging the CSS History Leak (via) Firefox is fixing the nefarious CSS visited link colour history leak flaw, which currently affects all browsers and allows a malicious site to determine if you have visited a specific site by checking getComputedStyle against a link to that page. It’s an obtrusive but necessary fix—visited link styles will be restricted to colour and border styles (no background images and hence no more checkbox effects since the image request could leak information) and those colours will not be reported via getComputedStyle. I hope other browser vendors follow suit.

# 31st March 2010, 8:01 pm / css, firefox, history, mozilla, security

HTML 5 audio player demo. Scott Andrew’s experiments with the HTML5 audio element (and jQuery)—straight forward and works a treat in Safari, but Firefox doesn’t support MP3. Presumably it’s not too hard to set up a fallback for Ogg.

# 1st February 2010, 9:58 am / audio, firefox, html5, javascript, jquery, mp3, ogg, safari, scott-andrew

HTML 5 Parsing. Firefox nightlies include a new parser that implements the HTML5 parsing algorithm (disabled by default), which uses C++ code automatically generated from Henri Sivonen’s Java parser first used in the HTML5 validator.

# 11th July 2009, 11:36 pm / browsers, firefox, henri-sivonen, html5, john-resig, mozilla, parsing, validator

Firefox 3.5 for developers. It’s out today, and the feature list is huge. Highlights include HTML 5 drag ’n’ drop, audio and video elements, offline resources, downloadable fonts, text-shadow, CSS transforms with -moz-transform, localStorage, geolocation, web workers, trackpad swipe events, native JSON, cross-site HTTP requests, text API for canvas, defer attribute for the script element and TraceMonkey for better JS performance!

# 30th June 2009, 6:08 pm / audio, browsers, canvas, crossdomain, csstransforms, dragndrop, firefox, firefox35, fonts, geolocation, html5, javascript, json, localstorage, mozilla, offlineresources, performance, textshadow, tracemonkey, video, webworkers

Browsing my browsing. Roo Reynolds used the MeeTimer Firefox extension to gather statistics on his browsing habits, then extracted data directly from the SQLite database and generated his own graphs using PHP and the canvas element.

# 10th April 2009, 8:48 am / canvas, firefox, javascript, meetimer, php, rooreynolds, sqlite

Pwn2Own trifecta: Hacker exploits IE8, Firefox, Safari. You just can’t trust browser security: Current versions of Safari, IE8 and Firefox all fell to zero-day flaws at an exploit competition. None of the vulnerabilities have been disclosed yet.

# 19th March 2009, 3:30 pm / browsers, firefox, ie8, internet-explorer, pwn2own, safari, security

Magic properties make Firefox synchronously load the Java plugin. Even defining a function called sun() (or several other symbols) will trigger the Java VM to be loaded, dramatically hurting the performance of your page.

# 27th February 2009, 4:03 pm / firefox, java, javascript, mark-pilgrim, performance