Software-update: Mozilla Firefox 139.0

Mozilla heeft versie 139 van zijn webbrowser Firefox uitgebracht. In deze uitgave is het onder meer mogelijk om de nieuwe tabpagina van een eigen achtergrond of kleur te voorzien, kan er een preview van een link worden getoond wanneer er op Alt+Shift wordt gedrukt en kan de volledige pagina op Mozilla's extensiepagina worden vertaald in een taal naar keuze. De complete changelog voor deze uitgave kan hieronder worden gevonden.

New

• By popular request, Full-Page Translations are now available within Firefox extension pages that start with the moz-extension:// URL scheme.
• The New Tab custom wallpaper (and colors) option is now available! Your own image can be uploaded as your New Tab wallpaper or any custom color can be selected - from the brightest pink to dark gray. This feature will be rolling out gradually to new users and can also be enabled immediately via Firefox Labs. Additionally, new Wallpaper images and a new Celestial category have also been added
• Link Previews is currently available as an experimental feature which can be enabled via Firefox Labs in the Firefox settings. After enabling, use the Alt+Shift keyboard shortcut when hovering over a link to see the previews in action!

Fixed

• PNG images with transparency now keep their transparency when pasted into Firefox.
• The upload performance of HTTP/3 has been significantly improved, particularly on resumed connections (QUIC 0-RTT) and high-bandwidth and high-delay connections.
• Various security fixes.

Changed

• Due to recent changes in how Chrome encrypts user data on Windows, the Firefox migration wizard can no longer directly import payment methods or passwords from Chrome. However, users can still export passwords from Chrome to a CSV file and then import them into Firefox using the migration wizard or the password manager.
• The Review Checker feature is shutting down and will no longer be available after June 10, 2025.

Enterprise

• You can find information about policy updates and enterprise specific bug fixes in the Firefox for Enterprise 139 Release Notes.

Developer

• Developer Information
• Based on user requests from both Mozilla Connect and Stack Overflow, the filter setting in the Network panel is now preserved across DevTools Toolbox sessions.
• The Debugger's directory root is now scoped to the specific domain where it was set, which aligns with typical usage and avoids applying it across unrelated domains. This builds on previous improvements such as a redesigned UI and easier removal of the root setting. Setting a directory root updates the Source List to show only the selected directory and its children. Learn more
• The appearance of the paused line in the Debugger has been refined for better visibility, especially in high contrast mode.

Web Platform

• The Temporal proposal, a better version of Date, is now enabled by default in Firefox.
• Timer throttling for Workers is now supported.
• Closed <details> elements are now searchable and can be automatically expanded if found via find-in-page.
• Firefox now supports the hidden=until-found attribute, allowing content to be found via find-in-page when it's otherwise hidden by default.
• window.getSelection().toString() now correctly returns the text serialization when text is selected in a text control, improving cross-browser interoperability on some sites.
• Added support for the WebAuthn largeBlob extension.
• Added support for requestClose() to HTMLDialogElement.
• The built-in editor for contenteditable and designMode now handles collapsible white-space(s) before block boundaries and white-space sequences between visible content more consistently with Chrome. As a result, Gecko no longer inserts a padding <br> element after white-space before a block boundary, aligning behavior with other browsers.

De volgende downloads zijn beschikbaar:
Mozilla Firefox 139.0 voor Windows (Nederlands)
Mozilla Firefox 139.0 voor Linux (Nederlands)
Mozilla Firefox 139.0 voor macOS (Nederlands)
Mozilla Firefox 139.0 voor Windows (Engels)
Mozilla Firefox 139.0 voor Linux (Engels)
Mozilla Firefox 139.0 voor macOS (Engels)
Mozilla Firefox 139.0 voor Windows (Fries)
Mozilla Firefox 139.0 voor Linux (Fries)
Mozilla Firefox 139.0 voor macOS (Fries)

Versienummer	139.0
Releasestatus	Final
Besturingssystemen	Linux, macOS, Windows 10, Windows Server 2016, Windows Server 2019, Windows 11, Windows Server 2022, Windows Server 2025
Website	Mozilla Foundation
Download	https://www.mozilla.org/en-US/firefox/all/#product-desktop-release
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (21)

[RGort10]

Leuk om te vermelden dat het meeste werk voor de Temporal proposal is verzet door 1 contributor, die niet werkt bij Mozilla. Dit is namelijk: André Bargull. Hulde

The Temporal proposal provides a replacement for Date, a long standing pain-point in the JavaScript language. This blog post describes some of the history and motivation behind the proposal. The Temporal API itself is well docmented on MDN.

Temporal reached Stage 3 of the TC39 process in March 2021. Reaching Stage 3 means that the specification is considered complete, and that the proposal is ready for implementation.

SpiderMonkey began our implementation that same month, with the initial work tracked in Bug 1519167. Incredibly, our implementation was not developed by Mozilla employees, but was contributed entirely by a single volunteer, André Bargull. That initial bug consisted of 99 patches, but the work did not stop there, as the specification continued to evolve as problems were found during implementation. Beyond contributing to SpiderMonkey, André filed close to 200 issues against the specification. Bug 1840374 is just one example of the massive amount of work required to keep up to date with the specification.

As of Firefox 139, we’ve enabled our Temporal implementation by default, making us the first browser to ship it. Sometimes it can seem like the ideas of open source, community, and volunteer contributors are a thing of the past, but the example of Temporal shows that volunteers can still have a meaningful impact both on Firefox and on the JavaScript language as a whole.

(bron: https://spidermonkey.dev/blog/2025/04/11/shipping-temporal.html)

[desalniettemin]

Ik ben forkserver aan het proberen:

https://www.phoronix.com/news/Firefox-ForkServer-Linux-Nears

Ik heb het aangezet in about:config dom.ipc.forkserver.enable

[rbr320]

Deze boolean staat bij mij standaard op "true", dus ik hoefde niets aan te passen.

[Technomania]

Net even aan het spelen geweest met tabbladen (en kleurtje geven) en het is best wennen dus snel weer terug gezet. Morgen verder spelen.


Offtopic: * Technomania heeft eigenlijk standaard 2 tabbladen Tweakers open staan.

[borbit]

Als ik naar het lijstje met updates naast het artikel kijk springen van 138.0.4 nog geen 10 dagen geleden naar 139. Wat is het idee om zo snel die nummers op te hogen? Deze update is toch niet een soort grote verandering ofzo ?

[Wouterie]

Ze doen een wedstrijdje wie het eerst bij de 1000 is. Chrome is bij 136 dus Firefox loopt een beetje voor.

Verder ben ik van mening dat je gelijk hebt. Vroeger stond een mayor release nog ergens voor... Maar aan de andere kant zit Windows 11 inmiddels ook al op 26100.4061. Maar ja, Windows 26100.4061 klinkt natuurlijk voor geen meter. Ook wel geinig is dat Windows 11 eigenlijk Windows NT 10 is, net als Windows 10.

Volgens mij doen ze maar wat.

[digibaro]

Wat dat betreft zou jaartal_maand_volgnummer mijn inziens een zinniger versie nummering zijn.

[Wouterie]

Euh... het blijven Amerikanen hè? Die hebben daar zo hun eigen ideeën over.

[borbit]

Dat is windows onder water héél veel versies heeft snap ik wel. Als je een of ander vaag probleem tegen komt wil je natuurlijk wel héél precies weten welke versie je hebt.

Maar van 10 naar 11 is voor mij als simpele gebruiker wel echt een grote en merkbare stap. Dan vind ik het wel logisch dat het van 10 naar 11 gaat. Het werkt (voor de simpele gebruiker) echt een beetje anders. Ik heb win11 best lang uitgesteld. Af en toe wel een uurtje geprobeerd, maar dan steeds toch maar terug naar win 10 omdat ik het meer gewend ben.

Sinds een week op werk over naar win 11 en na een paar dagen wennen kom je er toch wel achter dat de GUI toch wat fijner werkt. Nu sinds gisteren thuis toch maar overstag.

[Wouterie]

Ach, Microsoft... Ik doe nog wel eens wat systeembeheer en veel zaken zien er bijna net zo uit als Windows 2000 of misschien zelfs NT 4.0. Ik denk zelfs dat ik tegenwoordig veel meer doe in een console (PowerShell) net als vroeger in het Win98/DOS tijdperk, dan onder Windows Server 2008 R2

Maar ok, voor de eindgebruiker werkt het allemaal prima. Sommige zaken vind ik wat wonderlijk, zoals dat startmenu standaard in het midden en dat vervloekte rechtermuisknop menu waar niets meer te vinden is. Maar goed, er is niet wat niet weer terug te zetten is naar het oude.

Ik vraag me wel oprecht af waarom Windows 11 onder water nog steeds Windows NT 10 heet.

[borbit]

. Sommige zaken vind ik wat wonderlijk, zoals dat startmenu standaard in het midden en dat vervloekte rechtermuisknop menu waar niets meer te vinden is. Maar goed, er is niet wat niet weer terug te zetten is naar het oude.

Het is ondertussen gemakkelijk terug te zetten naar links. Ik ben gewend en dat was vroeger ook het idee denk ik om gewoon je muis die kant op te gooien en dan daar uit te komen. Ik kan me wel goed voorstellen dat de positie in het midden handiger als je een erg groot scherm hebt. En de midden optie was voorheen denk ik geen optie. Ik heb hem de eerste 2 dagen wel daar laten staan en ik vond het na enige gewenning niet echt onhandig. Daarna wel terug gezet op de vertrouwde plek. Het nieuwe rechtermuisknop menu vind ik niet top, maar heeft me ook nog niet echt in de weg gestaan.

Ik zie ook hele goede dingen. Het menu als je een venster omhoog speelt en dan een derde of vierde kan laten innemen vind ik echt top! Kon al wel, maar met dit nieuwe menu is het voor mij veel handiger.

En de mogelijk om een extra desktop te gebruiken is echt top, al heb ik nog geen 1 klik manier gevonden om te wisselen met de muis. En scrollen op het volume icoon is ook echt top voor mij. Beide functies die al sinds jaar en dag in veel Linux distro's zitten. Maar erg fijn dat het nu zonder extra apps in Windows zit.

Dat het onder water nog steeds werkt als Windows NT is lijkt mij juist een voordeel? De terminal moet wel gewoon een vaste manier van werken houden lijkt mij.

[Reactie gewijzigd door borbit op 27 mei 2025 21:33]

[Wouterie]

Ik moet bekennen dat ik het Start Menu eigenlijk niet meer gebruik: Ik druk de Start-knop in en typ wat ik wil hebben. Dat kon eerder ook al, maar nu doe ik niet anders meer. Dat veel hetzelfde is en werkt is uiteraard een voordeel, maar ik moet er wel om grinniken als ze weer komen met een nieuwe Windows, die er nog beter uitziet en 'helemaal vanaf de grond opnieuw is opgebouwd'... sure, na 2 minuten zit ik weer in dezelfde vertrouwde Microsoft Management Console (MMC) rond te klikken. Misschien helemaal vanaf de grond opnieuw opgebouwd, maar dan wel volgens dezelfde bouwtekening en met dezelfde bakstenen. Wel met een nieuwe voordeur en een ander behangetje.

Het rechtermuisknopmenu was met een registry edit weer 'goed' te zetten en het Start Menu hebben ze ook makkelijker gemaakt inderdaad. Ik vind het niet per se handiger dat het uitklapmenu nu nog meer uitklapmenu's heeft. Even snel van wifi-netwerk wisselen kost toch een klik extra!

Maar we dwalen volledig af hier...

[borbit]

Ik herken helemaal dat ik ook het startmenu veel minder gebruik. De meest gebruikte apps staan gewoon op de taakbalk. Dat maakt de positie link ook minder belangrijk. Je kan je muis wel die hoek ingooien maar dan moet je alsnog gaan muizen om bij je app buiten het start menu te komen. De Windows knop versterkt dat idee alleen maar. En puur om te kijken is het midden wel handig eigenlijk.

Dat het enkel een nieuwe deur en behang is maakt perfect sense eigenlijk. Ik zat hiervoor in de verbouw. En een nieuwe deur (om maar wat te noemen) is vaak echt een upgrade. Maar dat de eerste verdieping vloer op die hoogte zit is helemaal prima, daar wil je niks aan doen. (bij de meeste recente (30+ jaar) huizen)

Ik hoef niet onderwater maar het lijkt mij juist fijn dat de echte pro functies gewoon op dezelfde plek blijven zitten.

De extra klik om van WiFi te wisselen vind ik inderdaad wel storend!

[Reactie gewijzigd door borbit op 27 mei 2025 21:49]

[desalniettemin]

Het is veranderd van nieuwe versie elke 6 weken naar nieuwe versie elke 4 weken om zo veranderingen sneller aan te kunnen bieden of zoiets. Weet niet meer precies waarom.

[Loller1]

Jiij leeft al sinds 2009 onder een steen zeker?

[borbit]

Ik ben zeker niet dagelijks met versie nummers bezig. Ik vroeg me gewoon af waarom dit zo is. Ik zou het logischer vinden om van 138.0.4 bij kleine updates naar 138.0.5 te gaan. En dan voor grotere updates naar 138.1.0. En dan echt als er hele grote voor de consument merkbare veranderingen plaatsvinden naar 139.

Om maar iets toe noemen Ubuntu gaat ook maar 1 keer per jaar een heel nummer omhoog. (ja ik weet dat ze datum gebruiken). En bijvoorbeeld windows maar eens in de zoveel jaar een heel nummer omhoog terwijl er toch zeer regelmatig een update is.

Ik heb er verder niet echt veel kijk op, was gewoon benieuwd.

Wat is er in 2009 gebeurd?

[Reactie gewijzigd door borbit op 27 mei 2025 20:50]

[Bux666]

Eerder gebruikte Mozilla voor Firefox en Thunderbird semantic versioning. Maar toen Chrome op de markt kwam en Google besloot om steeds een major bump te doen tijdens de vaste updatecycles, kwam er een discrepantie tussen Chrome en Firefox. Dat deed mensen geloven dat bijv. Firefox 3.x veel ouder was dan Chrome 14.x. En dus trok Mozilla dat gelijk.

Je hebt helemaal gelijk wat betreft de versie nummering, maar die is bij Firefox, Thunderbird en Chrome nietszeggend geworden.

[RobertMe]

Wat is er in 2009 gebeurd?

Vast niks. Maar software development processen zijn ook niet "statisch". En door nieuwe tooling (Git (/Hg/Mercurial in het geval van Mozilla tot voor kort), continuous integration, ...) worden er al jaren ("sinds 2009") veel meer releases van heel wat software zijn. Waardoor elke release dus maar een klein aantal wijzigingen bevat die wel of niet een grote impact op de software hebben. Vroeger had je het scenario dat er werd gekeken welke tickets opgepakt zouden worden voor een nieuwe versie, werd daar (lang) aan gewerkt, werd daarna gestopt met ontwikkelen en ging je die grote nieuwe versie testen en bugfixen. Maar dat testen is tegenwoordig allemaal geautomatiseerd, op alle mogelijke soft- en hardware platformen. En voordat een wijziging (/pull request) gemerged is is al voor 90%+ duidelijk dat het gewoon echt (goed) werkt. En doordat de automatische tests"blijven lopen" weet je ook "100%" zeker dat een volgende ticket niet het vorige stuk maakt. Waardoor het ook letterlijk op elk moment mogelijk is om een nieuwe versie uit te geven. Die garantie v.w.b. stabiliteit op elk moment van de codebase valt in zoverre redelijk te garanderen. Terwijl dat vroeger absoluut niet het geval was, en er vooraf aan een release veel meer getest moest worden. En waar je vroeger nog alpha / beta / release candidates had over een periode van weken heeft tegenwoordig software meerdere release kanalen, in het geval van Firefox dus stable, nightly en ESR (Extended Support Release). Waarbij nightly dus ook dagelijkse builds zijn van de huidige stand van zaken. En die over het algemeen zeer prima bruikbaar (/stabiel) zullen zijn. Terwijl je vroeger met "daily builds" (effectief hetzelfde) veel meer risico op bugs / instabiliteit had.

En daarnaast dat vroeger ook daadwerkelijk aan "grote tickets" werd gewerkt en een ticket maanden in beslag kon nemen. Tegenwoordig wordt veel meer agile en in sprints gewerkt. Het liefst zijn tickets klein en in een paar uur tot paar dagen te programmeren. Waardoor je grote tickets dus opsplitst in kleine behappare dingen. Waardoor het dus ook weer makkelijker wordt om garantie over correctheid te geven (een wijziging van 1000 regels is veel moeilijker te doorgronden dan tientallen individueel gewijzigingde en gerevieuwde en geteste van 100 regels). Waardoor je dus ook weer automatisch uit komt op dat je elke 2 maanden of whatever "veel kleine wijzigingen" gedaan hebt, die soms een groot resultaat geven en soms zie je het resultaat pas na maanden werk / meerdere releases waar bv voorbereidend technisch werk in zit dat niet in een changelog / release notes vermeld wordt maar wel vereist is voor een grote zichtbare wijziging "op het eind" (zoals dus die nieuwe Temporal javascript API die nu vermeld staat als "standaard ingeschakeld". Dat is een super kleine wijziging. Maar de code hiervoor is mogelijk (/waarschijnlijk?) jaren aan gewerkt en de originele code zit er wellicht dus ook al jaren in. Alleen dan de afgelopen maanden "standaard uitgeschakeld" en daarvoor "niet te gebruiken").

En dan heb je nog de grote van het project. Bij een groot project, zoals Firefox (of Chrome) of de Linux kernel, of Home Assistant, of .... Bestaande uit honderdduizenden regels code is effectief elke wijziging klein. Op 100.000 regels code is een wijziging van 1000 regels nog maar 1%. En zie bv de Linux kernel. Die hebben nooit meer echt grote wijzigingen en daarbij is letterlijk jaren met het 2.6 versienummer gewerkt, waarbij 2.6.0 uit 2003 is en 2.6.38, de laatste, uit 2011. Waarbij die twee versies vast en zeker verschrikkelijk veel afwijken. Maar als je gaat kijken naar 2.6.0 en 2.6.1 of 2.6.37 en 2.6.38 zullen die wijzigingen (op het formaat van de Linux kernel) allemaal aan te merken zijn als "klein". En intussen worden nieuwe major version bumps (3.x naar 4.x, naar 5.x, ...) ook gewoon gedaan als Linus daar zin in heeft en het "versienummer hoog is". Volledig arbitrair dus. Omdat sommige releases "klein" zijn en andere "groot" maar ze relatief ten opzichte van het totaal allemaal "klein" zijn.
En daarom dat je nu ook meer en meer release versies als jaar.maand etc ziet. Het is toch altijd mogelijk om een release te maken en de code is op elk moment bruikbaar en stabiel. Waarom dan niet periodiek die code vrijgeven zodat gebruikers er sneller gebruik van kunnen maken, de "feedback loop" korter is (als er een bug is wordt die sneller gemeld, en zit de code van waarin die bug zit ook nog relatief vers in het geheugen van de ontwikkelaar, i.p.v. dat er een half jaar na ontwikkeling een bug report komt en het een "hie zat die code ook alweer in elkaar" oplevert).
En bij web services (SaaS) is het nog veel extremer. Doordat daar geen software gedistribueerd hoeft te worden naar gebruikers (die het moeten installeren) kan elke wijziging (na testen en reviewen) direct live worden gezet ("continuous delivery"). Bij bv GitHub is dat het geval. Als een ticket door het proces heen is (reviewen, automatische tests, ...) wordt deze direct op de website uit gerold. En door uitgebreide monitoring en logging (en bv monitoring van social media, of A/B tests, of staged rollout) hebben ze het ook snel in de gate als er iets fout gaat of verbeteringen nodig zijn. Die dan indien nodig ook weer meteen opgelost kunnen worden. Dus bv dat een nieuwe feature wordt uitgerold, en dat op basis van logging blijkt dat er meer errors optreden dan normaal, of gebruikers in een bepaald proces veel vaker afhaken / niet verder komen. En dat op basis daarvan meteen een onderzoek wordt gestart en wellicht zelfs binnen een half uur alweer een nieuwe "versie" is uitgerold met een fix, zonder dat je er als gebruiker iets van merkt.

[desalniettemin]

Het is een tijd terug veranderd van nieuwe versie elke 6 weken naar nieuwe versie elke 4 weken.

[Infor40]

Wat mij wat ontgaat is dat nu binnen Ubuntu de Snap-versie nog niet beschikbaar is, maar je DEB al wel kunnen binnenhalen vanuit FF zelf direct. Het argument om snap te gebruiken was toch juist een snellere uitrol van bijv. issues? Nu snap ik wel dat een package gemaakt door Mozilla zelf niet gelijk staat aan een van Canonical en dat daar een slag tussen zit. Maar ergens ontgaat me de logica nu toch een beetje.

Verzeilde weer wat in de Snap vs DEB discussie omdat ik WebMidi niet aan de praat kreeg... dat is dus weer zoiets dat lastig is met de sandbox.

[Alex3]

Na twee dagen alweer een nieuwe update, 139.0.1:

Fixed graphics corruption with certain NVIDIA graphics adapters and multiple monitors running at mixed refresh rates after updating to Firefox 139. (Bug 1968876)