fidzu : thunderbird

Modern computer displays have gained more colorful capabilities in recent years with High Dynamic Range (HDR) being a headline feature. These displays can show vibrant shades of red, purple and green that were outside the capability of past displays, as well as higher brightness for portions of the displayed videos.

We are happy to announce that Firefox is gaining support for HDR video on Windows, now enabled in Firefox Nightly 148. This is experimental for the time being, as we want to gather feedback on what works and what does not across varied hardware in the wild before we deploy it for all Firefox users broadly. HDR video has already been live on macOS for some time now, and is being worked on for Wayland on Linux.

To get the full experience, you will need an HDR display, and the HDR feature needs to be turned on in Windows (Settings -> Display Settings) for that display. This release also changes how HDR video looks on non-HDR displays in some cases: this used to look very washed out, but it should be improved now. Feedback on whether this is a genuine improvement is also welcome. Popular streaming websites may be checking for this HDR capability, so they may now offer HDR video content to you, but only if HDR is enabled on the display.

We are actively working on HDR support for other web functionality such as WebGL, WebGPU, Canvas2D and static images, but have no current estimates on when those features will be ready: this is a lot of work, and relevant web standards are still in flux.

Note for site authors: Websites can use the CSS video-dynamic-range functionality to make separate HDR and SDR videos available for the same video element. This functionality detects if the user has the display set to HDR, not necessarily whether the display is capable of HDR mode. Displaying an HDR video on an SDR display is expected to work reasonably but requires more testing - we invite feedback on that.

Notes and limitations:

• Some streaming sites offer HDR video only if the page is on an HDR-enabled display at the time the page is loaded. Refreshing the page will update that status if you have enabled/disabled HDR mode on the display or moved the window to another display with different capabilities. On the other hand, you can use this behavior to make side-by-side comparisons of HDR and non-HDR versions of a video on these streaming sites if that interests you.
• Some streaming sites do not seem to offer HDR video to Firefox users at this time. This is not necessarily a problem with the HDR video functionality in Firefox; they may simply use codecs we do not currently support.
• Viewing videos in HEVC format on Windows may require obtaining 'HEVC Video Extensions' format support from the Microsoft Store. This is a matter of codec support and not directly related to HDR, but some websites may use this codec for HDR content.
• If you wish to not be offered HDR video by websites, you can set the pref 'layout.css.video-dynamic-range.allows-high' to false in about:config, we may decide to add this pref to the general browser settings if there is interest. Local files and websites that only offer HDR videos will still be HDR if the encoding is HDR.
• If you wish to experiment with the previous 'washed out' look for HDR video, you can set the pref 'gfx.color_management.hdr_video' to false. This is unlikely to be useful, but if you find you need to use it for some reason we would like to know (file a bug on Bugzilla).
• No attempt has been made to read and use HDR metadata in video streams at this time. Windows seems to do something smart with tonemapping for this in our testing, but we will want to implement full support as in other browsers.
• On the technical side: we're defining HDR video as video using the BT2020 colorspace with the Perceptual Quantizer (PQ) transfer function defined in BT2100. In our observations, all HDR video on the web uses this exact combination of colorspace and transfer function, so we assume all BT2020 video is PQ as a matter of convenience. We've been making this assumption for a few years on macOS already. The 'washed out' HDR video look arose from using the stock BT2020 transfer function rather than PQ, as well as the use of a BGRA8 overlay. Now we use the RGB10A2 format if the colorspace is BT2020, as HDR requires at least 10 bits to match the quality of SDR video. Videos are assumed to be opaque (alpha channel not supported): we're not aware of any use of transparency in videos in the wild. It would be interesting to know if that feature is used anywhere.

16 Jan 2026 2:40am GMT

This blog post is written both as a heads-up to embedders of SpiderMonkey, and an explanation of why the changes are coming

As an embedder of SpiderMonkey one of the decisions you have to make is whether or not to provide your own implementation of the job queue.

The responsibility of the job queue is to hold pending jobs for Promises, which in the HTML spec are called 'microtasks'. For embedders, the status quo of 2025 was two options:

1. Call JS::UseInternalJobQueues, and then at the appropriate point for your embedding, call JS::RunJobs. This uses an internal job queue and drain function.
2. Subclass and implement the JS::JobQueue type, storing and invoking your own jobs. An embedding might want to do this if they wanted to add their own jobs, or had particular needs for the shape of jobs and data carried alongside them.

The goal of this blog post is to indicate that SpiderMonkey's handling of Promise jobs is changing over the next little while, and explain a bit of why.

If you've chosen to use the internal job queue, almost nothing should change for your embedding. If you've provided your own job queue, read on:

What's Changing

1. The actual type of a job from the JS engine is changing to be opaque.
2. The responsibility for actually storing the Promise jobs is moving from the embedding, even in the case of an embedding provided JobQueue.
3. As a result of (1), the interface to run a job from the queue is also changing.

I'll cover this in a bit more detail, but a good chunk of the interface discussed is in MicroTask.h (this link is to a specific revision because I expect the header to move).

For most embeddings the changes turn out to be very mechanical. If you have specific challenges with your embedding please reach out.

Job Type

The type of a JS Promise job has been a JSFunction, and thus invoked with JS::Call. The job type is changing to an opaque type. The external interface to this type will be JS::Value (typedef'd as JS::GenericMicroTask);

This means that if you're an embedder who had been storing your own tasks in the same queue as JS tasks you'll still be able to, but you'll need to use the queue access APIs in MicroTask.h. A queue entry is simply a JS::Value and so an arbitrary C address can be stored in it as a JS::PrivateValue.

Jobs now are split into two types: JSMicroTasks (enqueued by the JS engine) and GenericMicroTasks (possibly JS engine provided, possibly embedding provided).

Storage Responsibility

It used to be that if an embedding provided its own JobQueue, we'd expect them to store the jobs and trace the queue. Now that an embedding finds that the queue is inside the engine, the model is changing to one where the embedding must ask the JS engine to store jobs it produces outside of promises if it would like to share the job queue.

Running Micro Tasks

The basic loop of microtask execution now looks like this:

JS::Rooted<JSObject*> executionGlobal(cx)
JS::Rooted<JS::GenericMicroTask> genericTask(cx);
JS::Rooted<JS::JSMicroTask> jsTask(cx);

while (JS::HasAnyMicroTasks(cx)) {
  genericTask = JS::DequeueNextMicroTask(cx); 

  if (JS::IsJSMicroTask(genericTask)) {
    jsMicroTask = JS::ToMaybeWrappedJSMicroTask(genericMicroTask);
    executionGlobal = JS::GetExecutionGlobalFromJSMicroTask(jsMicroTask);

    {
      AutoRealm ar(cx, executionGlobal);
      if (!JS::RunJSMicroTask(cx, jsMicroTask)) {
        // Handle job execution failure in the 
        // same way JS::Call failure would have been
        // handled
      }
    }

    continue;
  }

  // Handle embedding jobs as appropriate. 
}

The abstract separation of the execution global is required to handle cases with many compartments and complicated realm semantics (aka a web browser).

An example

In order to see roughly what the changes would look like, I attempted to patch GJS, the GNOME JS embedding which uses SpiderMonkey.

The patch is here. It doesn't build due to other incompatibilities I found, but this is the rough shape of a patch for an embedding. As you can see, it's fairly self contained with not too much work to be done.

Why Change?

In a word, performance. The previous form of Promise job management is very heavyweight with lots of overhead, causing performance to suffer.

The changes made here allow us to make SpiderMonkey quite a bit faster for dealing with Promises, and unlock the potential to get even faster.

How do the changes help?

Well, perhaps the most important change here is making the job representation opaque. What this allows us to do is use pre-existing objects as stand-ins for the jobs. This means that rather than having to allocate a new object for every job (which is costly) we can some of the time actually allocate nothing, simply enqueing an existing job with enough information to run.

Owning the queue will also allow us to choose the most efficient data structure for JS execution, potentially changing opaquely in the future as we find better choices.

Empirically, changing from the old microtask queue system to the new in Firefox led to an improvement of up to 45% on Promise heavy microbenchmarks.

Is this it?

I do not think this is the end of the story for changes in this area. I plan further investment. Aspirationally I would like this all to be stabilized by the next ESR release which is Firefox 153, which will ship to beta in June, but only time will tell what we can get done.

Future changes I can predict are things like

1. Renaming JS::JobQueue which is now more of a 'jobs interface'
2. Renaming the MicroTask header to be less HTML specific

However, I can also imagine making more changes in the pursuit of performance.

What's the bug for this work

You can find most of the work related to this under Bug 1983153 (sm-µ-task)

An Apology

My apologies to those embedders who will have to do some work during this transition period. Thank you for sticking with SpiderMonkey!

15 Jan 2026 5:00pm GMT

At Mozilla, we've long believed that technology can be built differently - not only more openly, but more responsibly, more inclusively, and more in service of the people who rely on it. As AI reshapes nearly every layer of the internet, those values are being tested in real time.

Our 2025 Mozilla Ventures Portfolio Convening Report captures how a new generation of founders is meeting that moment.

At the Mozilla Festival 2025 in Barcelona, from Nov. 7-9, we brought together 50 founders from 30 companies across our portfolio to grapple with some of the most pressing questions in technology today: How do we build AI that is trustworthy and governable? How do we protect privacy at scale? What does "better social" look like after the age of the global feed? And how do we ensure that the future of technology is shaped by people and communities far beyond today's centers of power?

Over three days of panels, talks, and hands-on sessions, founders shared not just what they're building, but what they're learning as they push into new terrain. What emerged is a vivid snapshot of where the industry is heading - and the hard choices required to get there.

Open source as strategy, not slogan

A major theme emerging across conversations with our founders was that open source is no longer a "nice to have." It's the backbone of trust, adoption, and long‑term resilience in AI, and a critical pillar for the startup ecosystem. But these founders aren't naïve about the challenges. Training frontier‑scale models costs staggering sums, and the gravitational pull of a few dominant labs is real. Yet companies like Union.ai, Jozu, and Oumi show that openness can still be a moat - if it's treated as a design choice, not a marketing flourish.

Their message is clear: open‑washing won't cut it. True openness means clarity about what's shared -weights, data, governance, standards - and why. It means building communities that outlast any single company. And it means choosing investors who understand that open‑source flywheels take time to spin up.

Community as the real competitive edge

Across November's sessions, founders returned to a simple truth: community is the moat. Flyte's growth into a Linux Foundation project, Jozu's push for open packaging standards, and Lelapa's community‑governed language datasets all demonstrate that the most durable advantage isn't proprietary code - it's shared infrastructure that people trust.

Communities harden technology, surface edge cases, and create the kind of inertia that keeps systems in place long after competitors appear. But they also require care: documentation, governance, contributor experience, and transparency. As one founder put it, "You can't build community overnight. It's years of nurturing."

Ethics as infrastructure

One of the most powerful threads came from Lelapa AI, which reframes data not as raw material to be mined but as cultural property. Their licensing model, inspired by Māori data sovereignty, ensures that African languages - and the communities behind them - benefit from the value they create. This is openness with accountability, a model that challenges extractive norms and points toward a more equitable AI ecosystem.

It's a reminder that ethical design isn't a layer on top of technology - it's part of the architecture.

The real competitor: fear

Founders spoke candidly about the biggest barrier to adoption: fear. Enterprises default to hyperscalers because no one gets fired for choosing the biggest vendor. Overcoming that inertia requires more than values. It requires reliability, security features, SSO, RBAC, audit logs - the "boring" but essential capabilities that make open systems viable in real organizations.

In other words, trust is built not only through ideals but through operational excellence.

A blueprint for builders

Across all 16 essays, a blueprint started to emerge for founders and startups committed to building responsible technology and open source AI:

• Design openness as a strategic asset, not a giveaway.
• Invest in community early, even before revenue.
• Treat data ethics as non‑negotiable, especially when working with marginalized communities.
• Name inertia as a competitor, and build the tooling that makes adoption feel safe.
• Choose aligned investors, because misaligned capital can quietly erode your mission.

Taken together, the 16 essays in this report point to something larger than any single technology or trend. They show founders wrestling with how AI is governed, how trust is earned, how social systems can be rebuilt at human scale, and how innovation looks different when it starts from Lagos or Johannesburg instead of Silicon Valley.

The future of AI doesn't have to be centralized, extractive or opaque. The founders in this portfolio are proving that openness, trustworthiness, diversity, and public benefit can reinforce one another - and that competitive companies can be built on all four.

We hope you'll dig into the report, explore the ideas these founders are surfacing, and join us in backing the people building what comes next.

The post How founders are meeting the moment: Lessons from Mozilla Ventures' 2025 portfolio convening appeared first on The Mozilla Blog.

14 Jan 2026 5:00pm GMT