Thank you. And thank you for making it open source.

Concerning this line: https://github.com/arkadiyt/zoom-redirector/blob/master/back... Why is it sometimes returning undefined? (or is that known)?

Cheers!

> Thank you. And thank you for making it open source.

Sure thing. All browser extension source code is available to you anyhow, even if the author doesn't publish it.

> Why is it sometimes returning undefined?

Looks like a simple bug as some folks below have pointed out. It doesn't impact the functionality of the extension in any way here.

Not the developer but nice catch. const match would be null, not undefined, if the regex search does not match, right?

In a browser console:

> const match = /^\/[js]\/(\d+)\/?$/.exec("something")

> undefined

The assignment to match returns undefined. The value of match is null.

To be pedantic the assignment returns null (always returns the rvalue[1]), it's the const statement that produces undefined[2]

[1] https://tc39.es/ecma262/multipage/ecmascript-language-statem... [2] https://tc39.es/ecma262/multipage/ecmascript-language-statem...

And to be even more pedantic, the function works because it is applied on an event listener... When null[1] is evaluated (in the right side of the || of the conditional), it produces a TypeError... which in effect (due to no catch and evaluation continuing in a parent/event-driven scope) is essentially equivalent to an empty return in this specific context.

What fun! :-)

Edit: apparently as also mentioned https://news.ycombinator.com/item?id=30268412

Run just /^\/[js]\/(\d+)\/?$/.exec("something") in the console

A function returns undefined if any value was not returned.

True generally, but irrelevant here: the function in question is RegExp.prototype.match. By definition, it never returns undefined, but only an array or null. The only way `match == undefined` could be true would be if smething had overridden RegExp.prototype.match, which would be… surprising and worthy of explicit note.

Also match[1] will never be undefined: it’ll either throw an exception, or be a string. No, this is just a bug, a poorly written guard that fails to guard what it was supposed to, and I suppose an exception is just silently swallowed and treated equivalently to the intended early return. But the clause should be changed to just `if (!match) return;` or similar.

Quick heads up you may want to update that to be === rather than ==, because of course JS is wonderful and null does == undefined (not a nerd snipe, I was just confused by your comment and went and looked at the code, and realized it was likely a typo :) )

Yeah, unfortunate typo, thanks for the correction. I spend most of my time writing Rust, and when I’m writing JavaScript I type !== and === naturally, but I think writing this comment I just didn’t quite switch into JavaScript mode.

Thanks for writing this - I've been using this for ages, and it's a recommended install for everyone at our company.

Missing only Safari, my browser of choice

Safari supports neither webRequestBlocking (for manifest v2 extensions) nor manifest v3 extensions. If they add support for either option then I can publish a Safari extension too.

Sign up for the Orion beta; it’s uses the Safari rendering engine and supports manifest v3 extensions

Wonderful! Thank you. Only if there was a way to do the same on iOS.