Basilisk 2023.05.17

Aller sur le site officiel

Basilisk est un navigateur internet "laboratoire", c'est-à-dire, que les développeurs le considère comme toujours en phase "bêta". Originellement crée par les développeurs de MoonChild Productions, éditeur du navigateur Pale Moon, il était destiné à tester certaines fonctions avant intégration à Pale Moon. Désormais, depuis août 2022, Basilisk vole de ses propres ailes grâce à une nouvelle équipe.

Toujours clone de Firefox et basé sur le moteur Goanna (fork de Gecko), cette nouvelle équipe continuera à développer le code (basé sur XUL) abandonné par l'équipe de Mozilla lors du basculement de Firefox 56 à 57 tout en le modernisant.

De ce fait, Basilisk est désormais un navigateur totalement indépendant et suit donc son propre rythme de mise à jour. Il est cependant disponible que sur Windows (à partir de Windows 7) et Linux. Une version compatible pour macOS ARM (M1/M2) est en préparation...

Basilisk
Version actuelle : 2023.05.17 - Voir les extensions disponibles
[🇺🇸] : Windows 32 bits, 64 bits | Linux

Notes de version de Basilisk 2023.05.17 (17/05/2023)

This is another important, major development update.
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 Basilisk, it may be a good idea to try them again with this release.
Special thanks to Job Bautista, martok, dbsoft, FranklinDM and Travis, and all other UXP contributors for continuing their hard work making this a reality!
This updates the UXP/Goanna platform version to 6.2.

  • 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's dom.window.event.enabled preference. See implementation notes.
  • Implemented self.structuredClone()
  • Implemented Element.replaceChildren. Once again primarily a web developer note.
  • Improved Shadow DOM :host matching.
  • 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 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_ntop() instead of the deprecated inet_ntoa().
  • 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 fontconfig on 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.
  • Merged the preference dom.getRootNode.enabled into the dom.webcomponents.enabled pref. 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.

Implementation notes

  • 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 Basilisk 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.event has 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 global window.event while 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 Basilisk, 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 getRootNode function 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.
Notes de versions complètes de Basilisk