Versie 32.2 van Pale Moon is uitgekomen. Deze webbrowser is ooit begonnen als een fork van Mozilla Firefox. Door optimalisaties voor moderne hardware en het weglaten van Accessibility-features en Parental Controls presteerde hij toen een stuk beter. Ook was er een 64bit-versie beschikbaar, ruim voordat Mozilla deze zelf aanbood. Intern werkt het op Goanna, een van Mozilla's Gecko afgeleide browserengine. De browser is beschikbaar voor Windows en Linux, en als bèta ook voor macOS en FreeBSD.
Vanaf versie 30 identificeert de browser zich naar buiten toe weer als een Firefox-browser, wat het eenvoudiger moet maken om oudere browserextensies te gebruiken. De download van Pale Moon is alleen in het Engels; een apart Nederlands taalbestand is beschikbaar. In deze uitgave zijn de volgende veranderingen en verbeteringen doorgevoerd:
Pale Moon version 32.2.0This is another important, major development update, continuing our rapid development efforts in the v32 milestone. With this version we should have restored web compatibility with the majority of reported problematic websites. If you were previously running into websites being problematic in Pale Moon, it may be a good idea to try them again with this release. Special thanks to Job Bautista, martok, dbsoft, FranklinDM and Travis for continuing their hard work making this a reality! This updates our UXP/Goanna platform version to 6.2.
Changes/fixes:Implementation notes:
- Implemented dynamic module imports. See implementation notes.
- Implemented exporting of async functions in modules.
- Implemented JavaScript class fields. See implementation notes.
- Implemented logical assignment operators
||=,&&=and??=.- Implemented a solution for websites using the officially deprecated ambiguous
window.event. This is disabled by default but can be enabled through about:config'sdom.window.event.enabledpreference. See implementation notes.- Implemented
self.structuredClone()(this may be very obscure to anyone except web developers. Apologies ;-) )- Implemented
Element.replaceChildren. Once again primarily a web developer note.- Improved Shadow DOM
:hostmatching.- Implemented WebComponents' CSS
::slotted()and related functionality.- Improved page caching in our memory allocator.
- Added support for FFmpeg 6.0, especially important for bleeding-edge Linux distros.
- Fixed a potential drawing deadlock for images, specifically SVG. This solves a number of hang-on-shutdown scenarios.
- Fixed various crashes related to WebComponents and our recent JavaScript work.
- Fixed various build-from-source issues on secondary target platforms.
- Fixed various small browser front-end scripting issues that could lead to errors or broken functionality.
- Fixed handling of async (arrow) functions declared inside constructors.
- Fixed various small JavaScript conformance issues.
- Fixed an issue where JavaScript (only in modules) would not properly create async wrappers.
- Updated the DOM Performance API to the current spec (User Timing L3).
See implementation notes, especially if you intend to use this in web content for critical functionality.- Updated keypress event handling to send keypress events on Ctrl+Enter.
- Updated internal JavaScript structures to make future porting easier, as well as improve JavaScript performance.
- Updated window handling and styling on Mac.
- Updated the Freetype lib to 2.13.0.
- Updated the Harfbuzz lib to 7.1.0.
- Updated our DNS lookup calls to use
inet_ntoa()instead of the deprecatedinet_ntop().- Updated the Fetch API to use the global's base URL instead of the entry document's base URL for spec compliance.
- We no longer support the outmoded
fontconfigon GTK systems.- We no longer parse or return the body of known-empty responses from servers (content-length of 0, or in case of HEAD or CONNECT methods).
- Implemented scaled font caching on GTK, improving performance.
- Fixed a build issue when building for Linux on ARM64 on later distros.
- Split out more parts of the browser into separate .dll files on Windows to reduce compiler strain and an oversized xul.dll
- Removed mozilla::AlignedStorage (code cleanup).
- Builds for FreeBSD now use xz for packaging instead of bzip2. By request, we now also offer GTK2 builds for FreeBSD.
- Merged the preference
dom.getRootNode.enabledinto thedom.webcomponents.enabledpref. See implementation notes.- Fixed a potential DoS issue with JPEG decoding.
- Fixed a potential issue in Windows widget code that could lead to crashes.
- Disabled potentially hazardous external protocols on Windows.
- Added known-problematic .dlls to the internal blocklist.
- Security issues addressed: CVE-2023-32209, CVE-2023-32214 and several others that do not have a CVE designation.
- UXP Mozilla security patch summary: 4 fixed, 1 rejected, 27 not applicable.
- JavaScript modules have various methods of being loaded into web page content. One of the later introduced methods is a function-style import() declaration, so-called "dynamic module imports" that has been used by various web frameworks, causing issues for Pale Moon resulting in blank pages in most cases (since the websites would not actually use document structure HTML, but rather JavaScript to create content, all from imported modules). This has been a major web compatibility issue lately and we're pleased to announce that this complex bit of machinery has been implemented.
- JavaScript's language specification is continuing to be watered down from a prototyping language towards a more "C-like" hybrid. As part of that effort, JavaScript classes were introduced in ECMAScript 6, and now further expanded in ES2022 with class fields and private class fields/methods, as well as statics. We should have a complete implementation of this now, which constitutes the more important parts of the ES2022 language update.
- The use of the outdated Microsoft Internet Explorer global
window.eventhas been a pervasive web compatibility issue for us, especially since it was officially deprecated and we never implemented this ambiguous and unreliable property that is highly-context sensitive. Websites should use the event as passed into the event handler to get the event source instead. However, since neither Chrome nor Firefox have dropped this and seem to be playing a game of "chicken", it remains in use on the web. To deal with this conflict, we have now implemented the equivalent behind a preference to enable users to (temporarily) use the globalwindow.eventwhile webmasters update their websites. We hope the Google camp will finally drop this one soon so we can be done with this legacy quirk.- The DOM Performance API was updated to the User Timing level 3 spec. It should be critically noted that the DOM Performance API was never designed to be used as a matter of course on published content, and was designed only for page performance analysis use by web designers. Of course, as part of making dev tools available to the web, a lot of abuse ensued because of the accurate navigation and timing measurements that this API can provide (looking at you, Google!). Because of tight integration with web content analysis, the older spec implementation we had was causing issues and actually breaking some services, so we updated it, but with a few important key differences:
- In Pale Moon, we keep navigation timing disabled because it's a notable privacy issue for the data it can gather (exact navigational events and timings). If you're a web dev and need these timing measurements, you can enable them with
dom.enable_performance_navigation_timing.- Our implementation, contrary to the spec, does not allow unlimited recording of performance events (effectively logging every page event!) which can also rapidly eat up memory. Instead we enforce a sane default quota that should be roomy enough for all legitimate use, but prevents runaway resource use or extensive logging of user actions.
- If the set quota is reached, a warning will be printed in the console and the recorded performance events will be thrown away. If you (foolishly) rely on Performance API events for your web application to function, be aware this may cause compatibility issues as the API was, again, not designed to be used in such a fashion. For event handling, there are much better alternatives available which do not involve extensive recording of user data or relying on a developer tool API.
- We've historically implemented the DOM
getRootNodefunction as it was being used in the wild as a standalone function, however its main intent has always been to be a helper function part of Shadow DOM/WebComponents. As such we have now merged the preference into the WebComponents preference, enabling and disabling it along with the rest of our WebComponents implementation.
:fill(white):strip_exif()/i/2004988410.jpeg?f=thumbmedium)
:strip_icc():strip_exif()/u/267941/crop5c176225de206_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/359001/crop619b9c75eefa9_cropped.jpg?f=community){kind=small}
/u/466919/Tweakers_p9_v2.png?f=community){kind=small}