Hmm... Firefox does have a setting that allows you to choose preferred theme for websites that have dark mode. And it has built-in screenshot tool but I'm not using either of those. I use Lightshot for screenshots.
Features missing in your current browser
- Thread starter Parkinsond
- Start date
But still the larger proportion of websites does not support dark theme; Opera (right click menu) and Yandex (side bar toggle) has the option; page loading with dark webpage flag is faster than that with dark reader.
I wouldn't mind a customizable toolbar like FF for Brave. I'm used to how Brave is, but when I first started using it, I had that thought in mind when comparing it to FF.
Edge could use more Customizable user interface, I have slimmed it down as much as possible, but there are still some annoyances, menu even shows disabled items.
Browsing data clearance on exit is part of any respectable browser and browsers update by themselves or via winget. I literally block or disable the other "features".
Browsing data clearance on exit is part of any respectable browser and browsers update by themselves or via winget. I literally block or disable the other "features".
Attachments
Among chromium browsers, Vivaldi is the most customizable, but it has other issues keeping me from using as the primary.
Firefox lacks a simple setting to disable JIT V8, which improves security but reduces performance in the settings, but it can be done in about:config.
@Bot
Can you list the JIT vulnerabilities in Chrome and Firefox in 2025 that would have been mitigated by disabling JIT?
@Bot
Can you list the JIT vulnerabilities in Chrome and Firefox in 2025 that would have been mitigated by disabling JIT?
Last edited:
Firefox doesn’t use V8 (that’s Chrome/Chromium’s JS engine) but you’re right that it has multiple JIT tiers you can turn off via about:config.
About your question (2025 JIT vulns)
I can’t reliably list “JIT vulnerabilities in Chrome and Firefox in 2025” because my information only goes up to late 2024. Anything I’d say about 2025‑specific CVEs or bugs would be guesswork, and I’d rather not invent data.
What I can say with confidence is:
- A large share of browser remote‑code‑execution bugs over the last years in both Chrome and Firefox have been in the JS engine JITs (V8 for Chrome/Chromium, SpiderMonkey JITs for Firefox).
- Disabling JIT normally prevents exploitation of bugs that depend on generating and executing JIT‑compiled code (many type‑confusion, bounds‑check‑elision, and optimization‑logic bugs), because the attacker loses the ability to get crafted native code emitted.
- It does not mitigate:
- Bugs in the JS interpreter or other engine components
- Vulnerabilities in WebAssembly (unless you also disable its JIT)
- Renderer sandbox escapes, GPU bugs, IPC issues, etc.
How you could track this yourself for 2025
If you want to know which 2025 bugs would likely be mitigated by disabling JIT, the most accurate way is:
- Chrome/Chromium
- Follow the Chrome Releases blog / security advisories for 2025.
- Look for vulnerabilities mentioning “V8”, “JIT compiler”, “JIT optimization”, or bugs in components like V8/JIT.
- Most “Type Confusion in V8” and similar bugs that rely on JIT‑optimized code paths are candidates that would be blocked or much harder to exploit with JIT disabled.
- Firefox
- Check Mozilla’s security advisories and Bugzilla bugs tagged with JavaScript Engine, JIT, IonMonkey, Warp, etc.
- Bugs explicitly described as JIT optimization / code‑generation issues are the ones where disabling the JIT is a likely mitigation.
Disabling JIT in Firefox (current way)
Since you mentioned Firefox:
In about:config, you can turn off its JIT tiers (names can vary slightly by version):
- Set javascript.options.baselinejit = false
- Set javascript.options.ion (or javascript.options.warp on newer builds) = false
- Optionally disable Wasm JIT too:
- javascript.options.wasm_baselinejit = false
- javascript.options.wasm_ionjit or similar = false
That gets you closer to a non‑JIT, interpreter‑only profile for sites where performance isn’t critical, and it should mitigate most SpiderMonkey JIT‑specific bugs (including future ones in 2025).
Bottom line
I can’t list 2025‑specific JIT CVEs yet, but historically a lot of serious Chrome/Firefox exploits have been in the JS JITs, and running without JIT would have mitigated or significantly hindered many of them. To get an exact list for 2025, you’d need to go through that year’s Chrome and Mozilla advisories and flag all vulnerabilities explicitly tied to their JIT components.
@Bot
I looked into it further.
All JIT vulnerabilities in Chrome in 2025 can be mitigated if Chrome is included in the MD exploit list.
In Firefox, there were four vulnerabilities that could not be mitigated.
I looked into it further.
All JIT vulnerabilities in Chrome in 2025 can be mitigated if Chrome is included in the MD exploit list.
In Firefox, there were four vulnerabilities that could not be mitigated.
- CVE-2025-3031
- CVE-2025-1933
- CVE-2025-11153
- CVE-2025-13024
You’re right that V8 = Chrome’s JS engine. For those 2025 Firefox CVEs, though, I have a hard limit:
I don’t have 2025 CVE details in my data, so I cannot reliably say whether disabling JIT would have mitigated CVE‑2025‑3031, CVE‑2025‑1933, CVE‑2025‑11153, or CVE‑2025‑13024. Anything specific I’d say about them would be guesswork.
What I can do is outline how you can check this accurately.
How to tell if a Firefox CVE is mitigated by disabling JIT
For each CVE:
- Find the Mozilla advisory
- Search: “CVE‑2025‑3031 site:mozilla.org” (and the others similarly).
- Open the corresponding Mozilla Foundation Security Advisory (MFSA).
- Locate the Bugzilla entry
- The MFSA almost always links to the underlying Bugzilla bug(s).
- Open each linked bug (some details might be restricted, but the Component and high‑level description are often visible).
- Check where the bug lives
If the Component is something like:- Core :: JavaScript Engine
- Core :: JavaScript Engine: JIT
- Core :: JavaScript: JIT</I> / IonMonkey / Warp
then it’s at least JS‑engine related. Next, look at the description or comments (when visible):
- If it mentions “JIT code”, “Ion/Warp optimization”, “baseline/Ion”, “compiled code”, etc., it’s likely JIT‑dependent. Disabling JIT would usually mitigate or greatly hinder exploitation.
- If it refers to interpreter paths, GC, or high‑level “memory safety before 2025‑xx‑xx”, it may affect both JIT and non‑JIT execution and would not necessarily be mitigated by disabling JIT.
[*]Check if the bug explicitly says “JIT‑only” or “affects non‑JIT”
Sometimes the summary or comments say things like:
- “Bug requires JIT‑compiled code path…” → disabling JIT very likely mitigates it.
- “Can be triggered in the interpreter” or no mention of JIT at all → disabling JIT probably does not fully mitigate it.
Why some “JIT bugs” may not be mitigated
Even when a CVE is tied to JS execution, it might not be purely JIT‑dependent:
- The bug is in shared JS engine code used by both interpreter and JIT.
- The exploit uses JIT for reliability but can be adapted to non‑JIT code paths.
- The CVE bundles several memory‑safety fixes under one ID (“memory safety bugs fixed in Firefox N+1”), not all of which are JIT‑only.
In such cases, Firefox without JIT can still be vulnerable, which might be what you’re seeing with those four CVEs.
Bottom line
Because I don’t have 2025 CVE write‑ups, I can’t definitively say whether those four specific Firefox vulnerabilities would have been mitigated by disabling JIT. The safest way is to follow the MFSA → Bugzilla chain for each CVE and see whether the bug is strictly in JIT‑generated code or also reachable via the interpreter.
If you want, you can paste the short MFSA descriptions for those four CVEs here (without any restricted Bugzilla content), and I can help interpret whether they sound JIT‑dependent or not.
Your colleague ChatGPT also has probable answers.
However, it is possible to conclude that unknown and undiscovered JIT vulnerabilities are probably more dangerous for Firefox than Chrome, if we consider what happened in 2025 to be statistically valid.
However, it is possible to conclude that unknown and undiscovered JIT vulnerabilities are probably more dangerous for Firefox than Chrome, if we consider what happened in 2025 to be statistically valid.
I'm really enjoying using Vivaldi! I prefer a clean design and the ability to disable features; Vivaldi offers that and much more!
Used Vivaldi several times; it is great, but has cpu-related issues.
I don't know about stats, but Vivaldi overall works better and faster than Chrome, Edge, and Firefox for me.
Vivaldi is slower to launch on my old HDD system, but it was not an issue on our kids' SSD systems when I tried Vivaldi.
The annoying issue with Vivaldi for me is the address bar choices or how it works. They always mess it up with an update and then fix it with another update. It has continued through the last few updates.
I set the address bar in a way that it shows only "typed" websites, i.e., no accessed pages or searches. They have again messed it up with the last update; the drop-down menu now also displays accessed pages.
When tested using speedometer, Vivaldi scored better than Chrome and Edge, but while palying YT videos and using Whatsapp web (with menu animation), it shows stutter and abover average cpu usage.
Reinstalled Vivaldi; seems YT issue is fixed, but still has its share of bugs like every browser (some websites do not load properly, while they do with Edge).
I asked chatgpt 5.1 (paid) it said:
I checked. There is current public data for those CVEs; but whether “just disabling JIT” in Mozilla Firefox would have mitigated them isn’t clearly guaranteed for all of them. Here’s what I found (and what remains uncertain).
What we know, and why disabling JIT
- For CVE-2025-1933, the vulnerability arises from a bug in the JIT compilation of WebAssembly i32 return values on 64-bit CPUs: the JIT might pick up leftover bits from adjacent memory, leading to corrupted or mis-typed values. NVD+1
- For CVE-2025-11153, the publicly documented issue is “JIT miscompilation in the JavaScript Engine: JIT component.” NVD+1
- For CVE-2025-13024, the issue is similarly “JIT miscompilation in the JavaScript Engine: JIT component.” cvedetails.com+1
In other words: the root cause is in JIT, so removing JIT should prevent those specific miscompilation-based attacks.
What we do
- For CVE-2025-3031, the description is “JIT optimization bug with different stack slot sizes” — again, a JIT-related flaw. Mozilla But publicly available mitigation guidance for this CVE doesn’t explicitly say “disabling JIT will mitigate.” The official fix is an update to Firefox 137, implying the maintainers considered patching safer than relying on a workaround. Mozilla
- For all these CVEs, the official mitigation advice from maintainers is to update to a patched version (e.g. Firefox 143.0.3 for CVE-11153; Firefox 145 for CVE-13024; Firefox 137 for CVE-3031) rather than to disable JIT. Mozilla+2Mozilla+2
- Disabling JIT may have unintended consequences. Many modern web-apps rely on JIT or WebAssembly for performance — disabling it might break functionality or severely degrade site behavior. Worse, even if JIT is disabled, there could be other non-JIT vulnerabilities (e.g. memory safety issues, WebGPU bugs, sandbox escapes) that remain exploitable. Indeed, the 2025 security rounds for Firefox fixed many vulnerabilities outside JIT. Mozilla+1
- There is no public “official statement by Mozilla” (that I found) saying “disabling JIT is an effective mitigation” for these specific CVEs — that means it’s not a trusted or guaranteed mitigation strategy according to vendor guidance.
My (informed) conclusion: yes — disabling JIT
If you disable JIT (and ideally WebAssembly) in Firefox on a 64-bit system, you would probably avoid exploitation of the mis-compilation bugs (CVE-1933, CVE-11153, CVE-13024, and quite possibly CVE-3031). However, you’d still be exposed to non-JIT vulnerabilities — and you’d degrade browser functionality.If you like, I can check whether there’s a documented configuration toggle (policy / about:config) for Firefox 2025 that cleanly disables JIT + WASM (or falls back to an interpreter), and how practical that is day-to-day. Want me to dig up that info now?
****************************************************************************************************
If the above is redundant info, sorry.
On that ChatGPT 5.1 answer and your conclusion, there are two separate points:I asked chatgpt 5.1 (paid) it said:
I checked. There is current public data for those CVEs; but whether “just disabling JIT” in Mozilla Firefox would have mitigated them isn’t clearly guaranteed for all of them. Here’s what I found (and what remains uncertain).
Since all three are explicitly tied to JIT (the just-in-time compiler), disabling JIT (or preventing JIT compilation of JS / WASM) would — in principle — disable the faulty component and eliminate the attack surface exploited by those vulnerabilities.
- For CVE-2025-1933, the vulnerability arises from a bug in the JIT compilation of WebAssembly i32 return values on 64-bit CPUs: the JIT might pick up leftover bits from adjacent memory, leading to corrupted or mis-typed values. NVD+1
- For CVE-2025-11153, the publicly documented issue is “JIT miscompilation in the JavaScript Engine: JIT component.” NVD+1
- For CVE-2025-13024, the issue is similarly “JIT miscompilation in the JavaScript Engine: JIT component.” cvedetails.com+1
In other words: the root cause is in JIT, so removing JIT should prevent those specific miscompilation-based attacks.
- For CVE-2025-3031, the description is “JIT optimization bug with different stack slot sizes” — again, a JIT-related flaw. Mozilla But publicly available mitigation guidance for this CVE doesn’t explicitly say “disabling JIT will mitigate.” The official fix is an update to Firefox 137, implying the maintainers considered patching safer than relying on a workaround. Mozilla
- For all these CVEs, the official mitigation advice from maintainers is to update to a patched version (e.g. Firefox 143.0.3 for CVE-11153; Firefox 145 for CVE-13024; Firefox 137 for CVE-3031) rather than to disable JIT. Mozilla+2Mozilla+2
- Disabling JIT may have unintended consequences. Many modern web-apps rely on JIT or WebAssembly for performance — disabling it might break functionality or severely degrade site behavior. Worse, even if JIT is disabled, there could be other non-JIT vulnerabilities (e.g. memory safety issues, WebGPU bugs, sandbox escapes) that remain exploitable. Indeed, the 2025 security rounds for Firefox fixed many vulnerabilities outside JIT. Mozilla+1
- There is no public “official statement by Mozilla” (that I found) saying “disabling JIT is an effective mitigation” for these specific CVEs — that means it’s not a trusted or guaranteed mitigation strategy according to vendor guidance.
If you disable JIT (and ideally WebAssembly) in Firefox on a 64-bit system, you would probably avoid exploitation of the mis-compilation bugs (CVE-1933, CVE-11153, CVE-13024, and quite possibly CVE-3031). However, you’d still be exposed to non-JIT vulnerabilities — and you’d degrade browser functionality.
If you like, I can check whether there’s a documented configuration toggle (policy / about:config) for Firefox 2025 that cleanly disables JIT + WASM (or falls back to an interpreter), and how practical that is day-to-day. Want me to dig up that info now?
****************************************************************************************************
If the above is redundant info, sorry.
(1) whether those specific CVEs are likely JIT‑mitigated, and
(2) what you can reasonably conclude statistically about Firefox vs Chrome.
1. About those four Firefox CVEs
Because my data stops in 2024, I still can’t independently verify the 2025 CVE and MFSA details your other assistant quoted. I can only reason from principles and from what you pasted.
From what you posted, all four are explicitly described as JIT/WebAssembly JIT miscompilations or optimization bugs. If those descriptions are accurate, then the theory is straightforward:
- If a vulnerability’s root cause is a bug in the JIT compiler (JS or Wasm), and
- The exploit requires the browser to generate and execute JIT‑compiled code along that faulty path,
then disabling JIT (and, for CVE‑2025‑1933, disabling or de‑JITing Wasm) should in principle prevent exploitation of that specific bug, because the vulnerable code path never runs.
So, under those assumptions, the other assistant’s direction is plausible:
- CVE‑2025‑1933 – Wasm JIT return‑value issue → disabling Wasm JIT should neutralize that path.
- CVE‑2025‑11153 / ‑13024 – “JIT miscompilation in JavaScript Engine: JIT component” → interpreter‑only JS should avoid those paths.
- CVE‑2025‑3031 – “JIT optimization bug with different stack slot sizes” → again JIT‑specific, so no JIT → no vulnerable optimization.
But there are important caveats:
- I can’t see the actual advisories/bugs, so I cannot guarantee that:
- the bugs aren’t triggered in some shared, non‑JIT path, or
- Firefox doesn’t still JIT parts of Wasm/JS even with your toggles (misconfig, partial disable, etc.).
- Mozilla does not advertise “disable JIT” as an official mitigation; their guidance is to update. That’s always the only safe assumption.
- Even if these four are JIT‑only, there are many other 2025 bugs in non‑JIT code; turning off JIT never makes you “safe”, it only removes one big class of bugs.
So: conceptually, yes—if those CVEs are truly JIT‑only, a fully JIT‑disabled Firefox very likely dodges them. I just can’t confirm each CVE’s scope from my side.
2. “Unknown JIT vulns are probably more dangerous in Firefox than Chrome”
Using 2025 as a “sample year” is understandable, but you should be careful drawing a strong statistical conclusion like:
“Unknown/undiscovered JIT vulnerabilities are probably more dangerous for Firefox than Chrome.”
A few reasons:
- One year is a tiny sample. Vendor focus, researcher interest, fuzzing campaigns, and even random luck can make one year look worse for one engine.
- Chrome/Chromium (V8) historically had a huge number of high‑profile JIT bugs exploited in the wild. Many exploit chains in the 201x–early 2020s era started with V8 issues. One “good” year doesn’t erase that.
- If—like you said—Chrome is on the MD exploit list and gets extra hardening/mitigations in your configuration, while Firefox doesn’t get equivalent targeted rules, then you’re partly measuring your hardening setup, not just the inherent danger of “unknown JIT vulns”.
- The exploitability of unknown bugs also depends on sandboxing, process model, mitigations (CFI, CFG, CET, etc.), and not just on “how buggy is the JIT”.
So I’d phrase it more cautiously, something like:
“Given my configuration (MD exploit rules for Chrome) and the pattern of 2025 JIT CVEs, a JIT‑enabled Firefox may present more residual JIT risk for me than Chromium‑based browsers in that specific period.”
That reflects what you actually know (your setup + that year’s data) without over‑generalizing about “unknown future JIT bugs” in an absolute sense.
3. Practical takeaway
For your own threat model, your current reasoning is sound:
- Chromium + MD exploit rules → you’ve seen that this mitigated all known 2025 Chrome JIT CVEs in your analysis.
- Firefox with JIT disabled (and ideally Wasm JIT off) → will likely neutralize many JIT‑only CVEs, including those four, assuming they’re correctly described.
Just keep in mind:
- Patch early; don’t rely on “disable JIT” as a long‑term substitute.
- Treat conclusions about “unknown future JIT bugs” as tentative, not as hard evidence that Firefox is categorically more dangerous than Chromium or vice‑versa.
If you want, you can post the short MFSA descriptions (just the public text) for those four CVEs here, and I can walk through, one by one, how likely a JIT‑off setup would be to block each type of bug in theory.
Post those websites. I'll see whether the website works here.
I asked chatgpt 5.1 (paid) it said:
I checked. There is current public data for those CVEs; but whether “just disabling JIT” in Mozilla Firefox would have mitigated them isn’t clearly guaranteed for all of them. Here’s what I found (and what remains uncertain).
Since all three are explicitly tied to JIT (the just-in-time compiler), disabling JIT (or preventing JIT compilation of JS / WASM) would — in principle — disable the faulty component and eliminate the attack surface exploited by those vulnerabilities.
- For CVE-2025-1933, the vulnerability arises from a bug in the JIT compilation of WebAssembly i32 return values on 64-bit CPUs: the JIT might pick up leftover bits from adjacent memory, leading to corrupted or mis-typed values. NVD+1
- For CVE-2025-11153, the publicly documented issue is “JIT miscompilation in the JavaScript Engine: JIT component.” NVD+1
- For CVE-2025-13024, the issue is similarly “JIT miscompilation in the JavaScript Engine: JIT component.” cvedetails.com+1
In other words: the root cause is in JIT, so removing JIT should prevent those specific miscompilation-based attacks.
- For CVE-2025-3031, the description is “JIT optimization bug with different stack slot sizes” — again, a JIT-related flaw. Mozilla But publicly available mitigation guidance for this CVE doesn’t explicitly say “disabling JIT will mitigate.” The official fix is an update to Firefox 137, implying the maintainers considered patching safer than relying on a workaround. Mozilla
- For all these CVEs, the official mitigation advice from maintainers is to update to a patched version (e.g. Firefox 143.0.3 for CVE-11153; Firefox 145 for CVE-13024; Firefox 137 for CVE-3031) rather than to disable JIT. Mozilla+2Mozilla+2
- Disabling JIT may have unintended consequences. Many modern web-apps rely on JIT or WebAssembly for performance — disabling it might break functionality or severely degrade site behavior. Worse, even if JIT is disabled, there could be other non-JIT vulnerabilities (e.g. memory safety issues, WebGPU bugs, sandbox escapes) that remain exploitable. Indeed, the 2025 security rounds for Firefox fixed many vulnerabilities outside JIT. Mozilla+1
- There is no public “official statement by Mozilla” (that I found) saying “disabling JIT is an effective mitigation” for these specific CVEs — that means it’s not a trusted or guaranteed mitigation strategy according to vendor guidance.
If you disable JIT (and ideally WebAssembly) in Firefox on a 64-bit system, you would probably avoid exploitation of the mis-compilation bugs (CVE-1933, CVE-11153, CVE-13024, and quite possibly CVE-3031). However, you’d still be exposed to non-JIT vulnerabilities — and you’d degrade browser functionality.
If you like, I can check whether there’s a documented configuration toggle (policy / about:config) for Firefox 2025 that cleanly disables JIT + WASM (or falls back to an interpreter), and how practical that is day-to-day. Want me to dig up that info now?
****************************************************************************************************
If the above is redundant info, sorry.
Yes, as I already wrote, the answers are uncertain.
On my PC, it is better not to disable JIT in Firefox because the Speedometer 3.1 test score is reduced by half.
Those who have a high-performance PC and notice little difference in results can decide whether disabling JIT is feasible in order to achieve better security.
You may also like...
-
Samsung Launches Windows Version of its Web Browser- Started by Gandalf_The_Grey
- Replies: 2
-
Firefox’s Tab Notes Feature Feels Genuinely Useful (For Me, At Least)- Started by lokamoka820
- Replies: 1
-
-
Expired Vovsoft Search Text In Files lifetime free
- Started by Brownie2019
- Replies: 0
-
SOpera presents Early Bird mode in Opera One to test upcoming features
- Started by Santiago Benavides García
- Replies: 0