animenewsnetwork.com/bbs/phpBB2/viewtopic.php?t=3187693 everybody there ignores that browsers have developer consoles these days :/

any of those users could have copypasted the output and some stupid dev would have realized of his cardinal Chromeist sin

instead... let's blame adblockers and Noscript

weird, I'm trying with a FF102 UA, and I still get the event.path error (but the site does load fine, albeit slow, on actual FF102ESR)

I guess it's the previous regex vomit error that throws everything out of whack, then derails into some obsolete Chromeist path?

the event.path error does happen later than the "SyntaxError: invalid regular expression flag s" one

offending regex for today: /[A-Za-zÀ-ž]+|\d+|./gs

flag s is "Allows . to match newline characters."

...which is FF78+

exactly why trying to use a mobile browser sucks epic balls. no dev console

fwiw.. SeaMonkey 2.53.17 Beta 1 is out.

might wanna say that in ya Blog ewong

Has hunspell support been dropped from seamonkey-2.53.17b1 or just the system-hunspell option?

Ah, just system-hunspell :-(

JamminUnit with the switch to webext language packs some thing didn't work any longer so mozilla dropped it.

To be honest I don't like Mozilla's "let's bundle each and every third party software" attitude. Didn't understand it for sqlite and I don't understand it for hunspell as well.

JamminUnit: it's called "vendoring", and if you're distributing software for several platforms including Linux binaries intended to run on one bazillon distros, it's actually the sanest option

of course it's a double edged sword, as usual

vendoring often implies "we've tested building on this specific version of libblah and don't support bugs reported against any other version because we can't test that"

this is a constant source of headaches for Linux distros

Or in other words "we're too lazy to do thorough testing" or "we're not willing to push fixes/changes back to upstream".

and it's not limited to Mozilla - web browsers in general are a terminal case

the web is dead, LLMs will replace all of us anyhow - so something like that

s/so/or/

oh yeah, AI is the new crypto

JamminUnit the problem is that Linux is too fragemented. Every new library version might change existing apis at will. Even if they are not changed it might introduce incompatibilities when e.g. paramters are treated differently in the new version. Ages ago we had minor and major versions with minor versions keeping api comatibility. No longer the case.

^parameters

ffmpeg is my favourite offender there

ffmpeg is on the "we believe having a stable API/ABI is for wimps" league

reminder that thanks to yet another FFmpeg API change, VLC no longer has VAAPI hwdec on Debian 12

in theory, if everything had at least backwards-compatibility in public APIs, perhaps excluding major version changes, it should be possible not to rely on specific versions

... but that'd probably be called "Tempting fate" by tvtropes.

tomman: why is that? Can it be avoided if you compile it all yourself?

I use mplayer and mpv mostly so maybe I haven't been hit by that.

wyatt8740: the story is... complex

basically every player had to adapt

mpv did

VLC did... on their still-unreleased 4.0 branch, for which there is not a release date yet (not even a public beta)

they refuse to backport the fixes to the current 3.0 branch (i.e. the one they ship and distros ship)

ah. VLC doesn't keep the source head public. :(

CLOSED WONTFIX SENDTHEPATCHES

they claim the changes are too intrusive and prefer to focus on getting 4.0 ready

...which already has a 2 year delay

I haven't been a fan of VLC for some time. Maybe that's part of why.

distros only had three options: 1) ship VLC as-is, and warn users that they will lose hardware decoding on Intel (and possibly some ARM SoCs too)

it just always felt less stable than mplayer (and mpv)

2) keep multiple FFmpeg versions

or 3) get rid of VLC and tell people to use mpv or something else

you remember the avconv disaster, of course?

(in debian, libav/ffmpeg infighting)

ah yeah, long sour memories

Of course, there is hacky workaround to restore VAAPI support to VLC without having to recompile anything

install libvdpau-va-gl1 (or its equivalent on your distro)

then set VLC to use VAAPU for both decoding and output

(tested on an ancient IBM Thinkcentre with a Radeon HD2600 running Debian 12 - surprisingly it works and it's very stable)

--VDPAU

hm, probably won't work on my pentium M laptop since that never had it to begin with

but for the rest, yeah i've used vdpau-va-gl1 before.

Does SeaMonkey even support video hardware decoding?

I believe yes it does

(honest question - never tried as I don't watch videos on web browsers)

and on which API does it rely for that?

va-api i think

tomman I think yes on Windows. It came only lately on Linux and needs webrender. Will be a long path to put this into 2.53. Don't hold your breath.

hm, i guess i was wrong :p

no1: I won't be holding my breath as, just like I said, I watch videos on Media Players™

on my powerbook G4 it's the only way i can; everything else has wrong-endian problems

sure, I'm missing on all the ads, tracking, and toxic comments, but hey, all I want to do is to WATCH A VIDEO

(and the reason I'll never pay for Netflix or anything with DRM, since they will never work with VLC/mpv/yt-dlp by design)

(under debian)

it is funny how much we are encouraged to spend our time removing copy protections on things by these companies that supposedly are just trying to protect their eye pee.