fidzu : thunderbird

Mozilla is pleased to announce that Amy Keating has joined Mozilla as Chief Business Officer (CBO).

In this role, Amy will work across the Mozilla family of organizations - spanning products, companies, investments, grants, and new ventures - to help ensure we are not only advancing our mission but also financially sustainable and operationally rigorous. The core of this job: making investments that push the internet in a better direction.

Keating takes on this role at a pivotal moment for Mozilla and for the responsible technology ecosystem. As Mozilla pursues a new portfolio strategy centered on building an open, trustworthy alternative to today's closed and concentrated AI ecosystem, the organization has embraced a double bottom line economic model: one that measures success through mission impact and commercial performance. Delivering on that model requires disciplined business leadership at the highest level.

"Mozilla's mission has never been more urgent - but mission alone isn't enough to bring about the change we want to see in the world," said Mark Surman, President of the Mozilla Foundation. "To build real alternatives in AI and the web, we need to be commercially successful, sustainable, and able to invest at scale. Our double bottom line depends on it. Amy is a proven, visionary business leader who understands how to align values with viable, ambitious business strategy. She will help ensure Mozilla can grow, thrive, and influence the entire marketplace."

This role is a return to Mozilla for Keating, who previously was Mozilla Corporation's Chief Legal Officer. Keating has also served on the Boards of Mozilla Ventures and the Mozilla Foundation. Most recently, Keating held senior leadership roles at Glean and Planet Labs, and previously spent nearly a decade across Google and Twitter. She returns to Mozilla with 20 years of professional experience advising and operating in technology organizations. In these roles - and throughout her career - she has focused on building durable businesses grounded in openness, community, and long-term impact.

"Mozilla has always been creative, ambitious, and deeply rooted in community," said Amy Keating. "I'm excited to return at a moment when the organization is bringing its mission and its assets together in new ways - and to help build the operational and business foundation that allows our teams and portfolio organizations to thrive."

As Chief Business Officer, Amy brings an investment and growth lens to Mozilla, supporting Mozilla's portfolio of mission-driven companies and nonprofits, identifying investments in new entities aligned with the organization's strategy, and helping to strengthen Mozilla's leadership creating an economic counterbalance to the players now dominating a closed AI ecosystem.

This work is critical not only to Mozilla's own sustainability, but to its ability to influence markets and shape the future of AI and the web in the public interest.

"I'm here to move with speed and clarity," said Keating, "and to think and act at the scale of our potential across the Mozilla Project."

Read more here about Mozilla's next era. Read here about Mozilla's new CTO, Raffi Krikorian.

The post Mozilla welcomes Amy Keating as Chief Business Officer appeared first on The Mozilla Blog.

12 Jan 2026 7:31pm GMT

In our work on Firefox MacOS accessibility we routinely run into highly nuanced bugs in our accessibility platform API. The tree structure, an object attribute, the sequence of events, or the event payloads, is just off enough that we see a pronounced difference in how an AT like VoiceOver behaves. When we compare our API against other browsers like Safari or Chrome, we notice small differences that have out-sized user impacts.

In cases like that, we need to dive deep. XCode's Accessibility Inspector shows a limited subset of the API, but web engines implement a much larger set of attributes that are not shown in the inspector. This includes an advanced, undocumented, text API. We also need a way to view and inspect events and their payloads so we can compare the sequence to other implementations.

Since we started getting serious about MacOS accessibility in Firefox in 2019 we have hobbled together an adhoc set of Swift and Python scripts to examine our work. It slowly started to coalesce and formalize into a python client library for MacOS accessibility called pyax.

Recently, I put some time into making pyax not just a Python library, but a nifty command line tool for quick and deep diagnostics. There are several sub commands I'll introduce here. And I'll leave the coolest for last, so hang on.

pyax tree

This very simply dumps the accessibility tree of the given application. But hold on, there are some useful flags you can use to drill down to the issue you are looking for:

--web

Only output the web view's subtree. This is useful if you are troubleshooting a simple web page and don't want to be troubled with the entire application.

--dom-id

Dump the subtree of the given DOM ID. This obviously is only relevant for web apps. It allows you to cut the noise and only look at the part of the page/app you care about.

--attribute

By default the tree dumper only shows you a handful of core attributes. Just enough to tell you a bit about the tree. You can include more obscure attributes by using this argument.

--all-attributes

Print all known attributes of each node.

--list-attributes

List all available attributes on each node in the tree. Sometimes you don't even know what you are looking for and this could help.

Implementation note: An app can provide an attribute without advertising its availability, so don't rely on this alone.

--list-actions

List supported actions on each node.

--json

Output the tree in a JSON format. This is useful with --all-attributes to capture and store a comprehensive state of the tree for comparison with other implementations or other deep dives.

pyax observe

This is a simple event logger that allows you to output events and their payloads. It takes most of the arguments above, like --attribute, and --list-actions.

In addition:

--event

Observe specific events. You can provide this argument multiple times for more than one event.

--print-info

Print the bundled event info.

pyax inspect

For visually inclined users, this command allows them to hover over the object of interest, click, and get a full report of its attributes, subtree, or any other useful information. It takes the same arguments as above, and more! Check out --help.

Getting pyax

Do pip install pyax[highlight] and its all yours. Please contribute with code, documentation, or good vibes (keep you vibes separate from the code).

12 Jan 2026 12:00am GMT

Also known as "you can just put whatever you want in a jitdump you know?"

When you profile JIT code, you have to tell a profiler what on earth is going on in those JIT bytes you wrote out. Otherwise the profiler will shrug and just give you some addresses.

There's a decent and fairly common format called jitdump, which originates in perf but has become used in more places. The basic thrust of the parts we care about is: you have names associated with ranges.

Of course, the basic range you'd expect to name is "function foo() was compiled to bytes 0x1000-0x1400"

Suppose you get that working. You might get a profile that looks like this one.

This profile is pretty useful: You can see from the flame chart what execution tier created the code being executed, you can see code from inline caches etc.

Before I left for Christmas break though, I had a thought: To a first approximation both -optimized- and baseline code generation is fairly 'template' style. That is to say, we emit (relatively) stable chunks of code for either one of our bytecodes, in the case of our baseline compiler, or for one of our intermediate-representation nodes in the case of Ion, our top tier compiler.

What if we looked more closely at that?

Some of our code is already tagged with AutoCreatedBy, and RAII class which pushes a creator string on, and pops it off when it's not used. I went through and added AutoCreatedBy to each of the LIR op's codegen methods (e.g. CodeGenerator::visit*). Then I rigged up our JITDump support so that instead of dumping functions, we dump the function name + whole chain of AutoCreatedBy as the 'function name' for that sequence of instructions generated while the AutoCreatedBy was live.

That gets us this profile

While it doesn't look that different, the key is in how the frames are named. Of course, the vast majority of frames just are the name of the call instruction... that only makes sense. However, you can see some interesting things if you invert the call-tree

For example, we spend 1.9% of the profiled time doing for a single self-hosted function 'visitHasShape', which is basically:

masm.loadObjShapeUnsafe(obj, output);
  masm.cmpPtrSet(Assembler::Equal, output, ImmGCPtr(ins->mir()->shape()),
                 output);

Which is not particularly complicated.

Ok so that proves out the value. What if we just say... hmmm. I actually want to aggregate across all compilation; ignore the function name, just tell me the compilation path here.

Woah. Ok, now we've got something quite different, if really hard to interpret

Even more interesting (easier to interpret) is the inverted call tree:

So across the whole program, we're spending basically 5% of the time doing guardShape. I think that's a super interesting slicing of the data.

Is it actionable? I don't know yet. I haven't opened any bugs really on this yet; a lot of the highlighted code is stuff where it's not clear that there is a faster way to do what's being done, outside of engine architectural innovation.

The reason to write this blog post is basically to share that... man we can slice-and-dice our programs in so many interesting ways. I'm sure there's more to think of. For example, not shown here was an experiment: I added AutoCreatedBy inside a single macro-assembler method set (around barriers) to try and see if I could actually see GC barrier cost (it's low on the benchmarks I checked yo).

So yeah. You can just... put stuff in your JIT dump file.

Edited to Add: I should mention this code is nowhere. Given I don't entirely know how actionable this ends up being, and the code quality is subpar, I haven't even pushed this code. Think of this as an inspiration, not a feature announcement.

08 Jan 2026 9:46pm GMT