[notice of availability] Node.js daemon-only bridge

[warren-bank]

Hi Matt, @hensm

First off.. great work! I only installed this extension a few days ago, and it works so well on the few 1st-gen Chromecasts that I have.. laying around, gathering dust. Truly, I actually like it's UX better than in Chrome.

Funny to think that these old devices work great with Hulu, whereas my Android boxes cannot.. because the Hulu app's minSDK requires a newer version of Android.

Personally, when I'm using Windows OS:

1. I refuse to use anything newer than Win7
2. I only use PortableApps.. never install anything globally or touch the Windows registry

Admittedly, that's quirky..
in any case, to satisfy my own preferences..
I spent a few hours and made a fork of your bridge that doesn't use native messaging,
and consequently.. can run the WebSocket server in Node.js

It works great, so I figured that I'd share..
I'd ask that you consider offering the same as an official version,
but in the meanwhile.. I've published my fork to npm.

As a technical note, the only major change that I made to the code was to replace your dependency on mdns with node-dns-sd.. and wrote a little wrapper library to emulate the same events. This removes a ton of headache w/ the installation requirements of the former.

Also, I should mention.. that (aside from my own contributions) the code is generated by tsc and formatted for readability by prettier.. which is quick and easy, but doesn't produce the most elegant-to-read code. I didn't bother to rewrite it.. "if it ain't broke".. and such.

---

OK, announcement done.
Now, I'd like to quickly ask a question..

Regarding the different UX between fx_cast and native Chrome..

1. I notice that the cast session doesn't stop when Firefox windows are closed, or the browser is exited
   • which is a huge improvement
2. my question pertains to the inability to start a cast session from insecure web pages (ie: http: rather than https:)
   • this used to work in Chrome, then Chrome decided to disallow this functionality
   • I notice that this functionality is also disallowed in fx_cast
     • is there any way to make this work?
     • update: I spoke too soon, I just tested this functionality again.. now that I'm more familiar with fx_cast.. and can confirm that it can start (and manage) a cast session from insecure (ie: http:) pages.. excellent!
     • update: more specifically..

       HTML5 video player	https:	http:
       Video.js	✓	✓
       Clappr	✓	✗
       THEOplayer	✗	✗
       VisualOn	✗	✗

Thanks again.. 😃

[warren-bank]

follow-up deep-dive into observed Clappr behavior:

https://github.com/clappr/clappr-chromecast-plugin/commits/master/
clappr/clappr-chromecast-plugin@886b3fe

• commit: Feb 7, 2019
• note: adds check for whether window.location.protocol is secure

https://github.com/clappr/clappr-chromecast-plugin/blob/886b3fe00108b01e6c6437c6583173bf4d571737/package.json#L3

• version in repo at time of commit: 0.1.0

https://github.com/clappr/clappr-chromecast-plugin/releases

• version 0.1.0 was released on Dec 9, 2018
• version 0.1.1 was released on Feb 8, 2019
• note: version 0.1.1 is the most recent version in npm.. and consequently in cdn.jsdelivr.net@latest

why does this work:

• strictly speaking, the code's logic indicates that it should only work in Chrome browsers… period
  • v0.1.0
  • v0.1.1
• will need to examine the Browser class to figure out why it works in Firefox at all…TBD
• update: Browser uses navigator.userAgent for identification
• update:
  • observations…
    • default value (ex: on github):
      Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
    • value on a page that has been added to the fx_cast extension's URL whitelist:
      Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36
  • conclusions:
    • brilliant!… the fx_cast extension must be modifying the value of navigator.userAgent…
      so Clappr thinks that the page is loaded in Chrome 😃

summary:

• to use Clappr with fx_cast on insecure http: pages, either…
  1. the clappr-chromecast-plugin needs to be pinned at v0.1.0
  2. the User-Agent string used by the fx_cast extension's URL whitelist can be modified to trick Clappr v0.1.1 into believing that the page is loaded in Chrome version <= 71
     • here is where the magic happens… where the ua parameter is equal to navigator.userAgent
     • Chrome 71 does the trick 😃

[hensm]

Thanks for the kind words. I’m happy you’re finding it useful.

I see you’ve already answered your own question. As you’ve discovered, there is no restriction set by this extension, but it's understandable that a sender application distributed as a library used by unknown third parties has its own feature checks. Glad you've found a solution.

Some random thoughts:

The mdns module is troublesome: it’s no longer maintained and is broken on modern versions of Node, the Bonjour dependency install process on Windows is less than ideal and even on Linux, there are quirks with the way it interacts with Avahi. I’ve toyed with replacing it for ages, but never been particularly happy with the alternatives.

I don’t like the idea of using a purely JavaScript implementation for a couple reasons. Most systems have a built-in mdns daemon that listens on port 5353 (Bonjour on macOS, DNS Client on Windows 10/11, and Avahi or systemd-resolved on Linux). They’re just likely to be much better implementations; the JavaScript ones I’ve used in the past have been flaky. They’re also lower-overhead, sharing a cache with all applications on the system and the fewer things involved in multicast, the better, in my opinion.

Ideally, I’d just call those APIs. It’s a bit annoying since I’d have to write it at least twice, possibly three times, for the different platforms, plus the Node bindings.

Maybe in-process service discovery could be an acceptable opt-in fallback for platforms where there isn’t a system implementation available? I don't think I mind that idea so much.