Hacker News Reader

Comment by danaliv | Hacker News Reader

"Sorry, this browser isn't compatible with Zoom Escaper. Please try Chrome on desktop."

How many times will we have to learn the lessons of the late '90s/'00s?

Creator of the Zoom Escaper here... Sadly it relies on a web audio feature that's chrome only. Also too bad because I use firefox as my primary browser.

Could you elaborate a little bit? Just curious about the technical side of creating this cool application.

It's the setSinkId function which let's you select an audio output (https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaEl...) but it looks like I was mistaken -- it should actually also work with Edge and Opera. Will update the message for clarity...

Looks like it is supported on Firefox, but disabled by default, and requires an about:config tweak: https://caniuse.com/?search=setSinkId

Its MDN doc (https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaEl...) shows it as a not-quite-finalized feature, but even so, seems odd to have a pref just for it.

Also of note that Firefox's Web Audio API implementation just isn't very good in general. It's my daily driver, but I won't run Airsonic in it, because after half an hour or so the music reliably starts glitching. Fine in every other client, so it's definitely a Firefox thing, and iO-808 [1] also calls it out in an alert if you go there in Firefox. (And also starts glitching out after a while, if you decide to ignore the alert and take your chances.)

Granted, a glitchy audio implementation might be just the thing for this use case...

[1] https://io808.com/

Thanks, every time I see such a message I wish it had an expandable paragraph telling me what prevents it working with Firefox.

Mentioing the info from kelnos' comment would be excellent.

It should work with Brave too.

I’m interesting in knowing as well which standard in particular is being used which only Chrome supports. I was under the impression that the Web Audio API[1] was fairly well supported cross all modern browsers.

1: https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_A...

Well done.

If someone wants to use this they should have no problem running in chrome.

Sure, morals are no problem to get over. But hey, what's the price of privacy to run some software?

Oh I’m sorry, did you pay for the development effort?

Of Chrome? I sure did. All of that information that Google has collected about me over the years without my say so has generated income for them.

If you ever used any of their services you agreed on a bunch of ToS.

Does that include all of those sites that include GA/GFonts/etc that I have zero control over? You don't have to use G/FB services to still be a money generator for them. To be a reader of this site and still not understand that, one must either be on ostrich or a new reader.

You do have control over, just don't load things from them. Google "no-script", "uBlock", etc.

Your biological and technological distinctiveness have already been absorbed by G if you seriously use the term Google in daily vernacular for search. tsk tsk. You are the borg.

Come on, it was a joke given the context of our conversation.

And you think a star trek borg reference wasn't?

My bad, I did not catch that.

Thanks for creating and for sharing with us! Disregard the negativity.

The negativity was probably meant for Chrome anyway.

The lesson of those times was to not rely upon proprietary APIs in browsers. (Like ActiveX or other IE-only extensions which were often used.)

When you see this warning nowadays, it's not usually about that, but about Firefox or Safari being behind in supporting already-specced APIs.

I disagree. Chrome, by virtue of its popularity, market power and technical prowess, pushes through new features. In addition to that, they also port features from ChromeOS. Most of these features are either not standard yet or would never be.

For example, the WebUSB APIs are still in draft community status but is already there in chrome. Presumably because they created it for chromeos, ported it to chrome and then submitted it to the standards body - in that order. They are definitely going to continue this. I don’t see chrome publishing and getting a standard approved before implementing it at all. It’s also how IE6 holdover came about.

Web developers aren’t supposed to rely on non-standard features because it’s tight coupling and will bite you if the browser ever stagnates. That’s the lesson I learnt from the whole IE6 saga.

https://en.wikipedia.org/wiki/WebUSB

Well, yeah, you shouldn’t make your site incompatible with browsers that don’t support non-specced features if you can avoid it. Which is what I said the lesson was.

But I like WebGL2 and SharedArrayBuffer and don’t feel bad blocking users until their browser catches up.

Yeah and Firefox still lacks full passwordless fido2 (ctap mode)

I agree. Every webdev should know by now that you also need to tell visitors the screen resolution that a webpage is best viewed with.

420x6969. Ultra portrait aspect ratio.

I miss visible visitor counters and guestbooks!

The main lesson of the time was that users don't care about some "plurality" or browsers, and will flock to the browser that has the more features or best speed or more adoption.

Yeah, safari is the new internet explorer.

The web decided to give up on the original tenets of graceful degradation and other such things.

The web of the 90s/00s was actually a lot more resilient and compatible and secure than the bullshit js SPAs we get jammed down our throats today.

Reply on news.ycombinator.com