Chrome's team should be blamed for favoring AVIF over JPEG-XL, not Google entirely.
142 karma · joined March 24, 2024
Chrome's team should be blamed for favoring AVIF over JPEG-XL, not Google entirely.
> And worse yet, I was just now told that CF "provide the troubleshooter as a quality-of-life tool and maintain it with best effort." So they aren't even committed to making it work while that was one of the very things that kept coming up in our meeting as it was the only tool remotely available to be able to test Pale Moon (other than testing internally which they seem unwilling to consider, as well) prior to them pushing things to production, so they are already going back on their promises.
> I'm really running out of what little patience I have left with CF. They have effectively not addressed our problems, not provided answers, not told me what behaviour is wrong or broken in Pale Moon (according to them), not provided any tools, and are now playing down the one thing we could use in some fashion as "best effort without commitments", while continuing to be gatekeepers for the Internet and access to large swathes of it. EU's Digital Markets Act is pretty clear about how that is not acceptable behaviour -- even if it was written initially to deal with "preferred bundled software" for operating systems, it does lay the groundwork for addressing unfair practices by other types of gatekeepers like CF.
> It has activity going back months. We’re talking searches and website interactions from long before I enabled this. features.
> Firefox just handed that history to the AI models to plough from, without telling me upfront.
Pretty concerning that Mozilla at this point has made sharing all of your browsing history the default, without even asking you about it. This is a beta version, which is pretty much like a release candidate in Firefox, being the next version to be published after all. This shouldn't have reached beta at all.
Anyway not looking forward to my userChrome CSS for tabs on bottom ending up broken again in the redesign
XSLT which is an application of XML allows you to do a for-each: https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...
Isn't that a situation where forking happens as "a last resort when projects become irredeemably captured or hostile" as the article writes?
I think you're the one who missed the point and haven't digested this blog post properly.
The reason why Chrome (also a Google product) removed it at first is more likely to be internal politics. Google is a very large corporation after all, with each faction within it having its own priorities and alignments. In the case of Chrome the team there are probably more aligned with the AVIF/AOM team than with Zurich/PIK when it came to the next-gen image format to be pushed (which would explain why Chrome did not have problems with Brotli, because there wasn't a competing Google faction that is developing a replacement for gzip).
Simply a consequence of multi-process' inter-process communication (IPC) swamping the task scheduler. Changing the title requires a message to be sent from a content process to the UI through IPC. If you sufficiently flood the IPC protocol with messages, it will bring your browser to a halt in its entirety because you're basically DoSing the browser's internal communications.
Single-process browsers (e.g. Pale Moon) and browsers that have previously been designed primarily with a single-process model in mind and only adopted multi-process later (Firefox, Safari) would've handled this better by at the very least not locking up the browser and eventually the OS with a runaway meltdown in memory allocation.
To test this theory I've forced the Brash code to run with `Brash.run({burstSize: 8000,interval: 1});` in the devtools console. Why the PoC author decided to arbitrarily restrict the running the PoC only to Chrome-based browsers, I don't know. If non-Chrome truly is not vulnerable we should be able to verify that for ourselves.
In a fresh profile of Pale Moon without add-ons (and immediately closing the devtools afterwards) the UI does slow down but it's still usable (and therefore the offending tab can be closed even after a while). If you never reopen devtools in the offending tab the memory never even reaches 1 GB. In the worst-case scenario where the browser would hang (which could happen if you try to open up devtools in the offending tab for example), the memory allocation doesn't get instantly out of control, and the OS will recognize that it's hanging and let you close it.
In Firefox the UI is still working somewhat but memory allocation is faster than Pale Moon (but a bit slower than Chrome). Memory becomes manageable though when you switch focus to another tab; it no longer allocates more memory and the garbage collector was able to free up memory in the offending tab's content process with the JavaScript engine no longer blocking it thanks to the said content process being suspended in the background. However the main UI process will still hold a lot of memory unless you switch back to the offending tab for the garbage collector to recognize it needs to free up memory there. And if you close the offending tab before that you get yourself a memory leak, i.e. the memory allocated by the UI process will never go away, at least until you rerun the Brash code again (where the garbage collector will then recognize there is memory to be freed in the UI process).
I don't know about Safari, I have no Apple device to test it with unfortunately.
Tried it today in an updated Nightly and the key points are still the same lol.
With so much hate towards LLMs right now (which isn't unjustified) being vented on the internet there's no doubt sysadmins will do the same here and niche user agents will again suffer.
That's not the problem people have with Firefox. One of the issues right now is that there are people who have intentionally opted-in to sharing "technical data" to Mozilla for the sole purpose of improving the browser, when in fact, it's not just for that but also for improving ad-tech which was never an intent those power users had in mind: https://www.quippd.com/writing/2025/03/12/mozilla-has-been-s...
The previous sync (Sync 1.1 aka Weave) used to protect against this scenario by not allowing any synced data to be decrypted at all (since the sync server does not have your secret key at all).