Caprine: Calls not working

Created on 16 Nov 2019  ·  25Comments  ·  Source: sindresorhus/caprine

It shows only a blank white window. Can't receive call either. It works on Chrome.

bug help wanted
Source
picture huylv
👍13 👀3

Most helpful comment

The next text is outdated, see update below

I have resolved this on my local testing electron app (Calls doesn't work there either.)
A basic electron app with app.loadURL("https://www.messenger.com") - it works there.

As @Cellule pointed out, there is some inconsistency (pretty big it seems) between electron's window.open and normal browser's so supporting 3rd party websites with their use of these APIs will be hard.

The problem is in that, when trying to open a new call, Messenger's scripts are trying to open a blank window (we can see that) and then further in, the new url location of that window is set.

Something like this (their code is obfuscated)

h = window.open("", "Group Call", "some other params");
h.location = k; // where k is a path looking like "/groupcall/lots/of/other/params"

Now, it seems this usage is completely incompatible with Electron. Normal browser would handle this and prefix the new location with your current hostname if you don't provide one in .open or in the new location itself.

For example doing the same on electron but without passing any args (just .open() ) and then, If the location I try to set isn't full URL with protocol and hostname (https://www.messenger.com/my/new/path instead of just /my/new/path) it reliably fails, unable to parse the URL.

Compared, on my Firefox it works as it is probably widely expected and that is, if you pass only new path, your current's window proto+hostname+path is automatically used as base for that path. So If I do this in a window with current location https://test.com/path then opening a new window and setting the location on it to /groupcall should result in loading https://test.com/path/groupcall. This is probably what Messenger script's expect.

For now I've resovled this using Proxys and hooking into the window opening to prefix the proto+host before any window location. For now I've been doing this in the Electron's preload.js, when I tried to apply this to Caprine the hooks were not propagated, which is caused by that contextIsolation: true setting for preload scripts and it might not be a good idea to turn that off (if you don't want some scripts having direct access to your data). Unluckily something is still broken even after disabling some of these. So I was unable to apply these hacks to Caprine.

I wrote all of the above yesterday and I will keep it there just for the "documentation" sake.

So, today I found out there is a Electron webcontent's setting that allows the window.location behavior to work like Chrome: nativeWindowOpen. Which is cool because it solves all of the above, at least in simple Electron app.

But, with Caprine this isn't that easy as there is a bit of logic around window-open event in index.ts (privacy logic too), this all might as well break it.

For example, without also setting allowpopups on the root webview, all new-window events now have url of about:blank#blocked instead of just about:blank, there are more differences and I just don't think it's worth it, it could break the current window-open url control.

TLDR

  • Doing newWindow.location = "/path" fails because at it seems, by default electron is trying to join the new-window's location (that window's window.location) with the new location (/path), but the new-window doesn't have valid location.href because it wasn't opened with one.
    w1 = window.open() // w1.location.href === "about:blank"
    In normal browser, as long as your new location is not valid URL on it's own (?) it would join the new path with current's window (the window from where you are opening the new-window) location, not the new-window's one.

Solutions

  • When open of Group Calls window is detected, additionally pre-set the location to https://www.messenger.com.
  • Leverage nativeWindowOpen

Edit: added nativeWindowOpen as another possible solution

picture wereii on 6 Apr 2020
❤3 👍3

All 25 comments

I'm experiencing this on my Windows 10 machines as well.

Hamish-GJP picture Hamish-GJP on 16 Nov 2019

Video call not working since few days.

AndroidStdio picture AndroidStdio on 16 Nov 2019

Should note that it also applies to regular voice calls.

FredrikAugust picture FredrikAugust on 14 Dec 2019
👍6

note : version 2.39.0 works fine

raphtabe picture raphtabe on 18 Dec 2019
❤4

note : version 2.39.0 works fine

Nice to know. Just downgraded and working great now!

huylv picture huylv on 19 Dec 2019
👍2

This is still an issue for all platforms. A reinstall of Caprine will temporarily fix call functionality but will break again after calls are made or received... There is no need to uninstall Caprine before reinstalling again.. Again. as stated above v2.39.0 does not contain _this_ bug.

jiffyjoker picture jiffyjoker on 26 Jan 2020
👍1

If you don't need Dark Mode, 2.39.0 is the way to go at the moment. It is very stable, at least from my own experience. To avoid auto-update on macOS, just rename the app to something else, e.g. _Caprine 2.39.app_. Can't speak for other platforms though.

huylv picture huylv on 28 Jan 2020
👍2

It's good that we've got a workaround which is a temporary downgrade. However, the issue is still persistent in version 2.43.0 while calls work just fine on Chrome and other browsers. Attached is the screenshot of the blank window which appears when you initiate/join calls.

Are there any updates on this?

Screen Shot 2020-03-03 at 4 34 46 PM

Rezonansowy picture Rezonansowy on 3 Mar 2020

fyi breaking commit seems to be 833c42b; i'm not well-versed with Electron but maybe someone can take a look in index.ts

flriancu picture flriancu on 7 Mar 2020

It's good that we've got a workaround which is a temporary downgrade. However, the issue is still persistent in version 2.43.0 while calls work just fine on Chrome and other browsers. Attached is the screenshot of the blank window which appears when you initiate/join calls.

Are there any updates on this?

Screen Shot 2020-03-03 at 4 34 46 PM

same here on Version 2.44.0 (2.44.0.1789)

Friedd picture Friedd on 20 Mar 2020

I did some digging with my limited knowledge of electron.

Messenger will open a window with about:blank create a call then change the url of that window to the call.
However, since electron 7, the new window never receives the new url.

I did a very simple test with the following html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <script>
      function onClick() {
        const linkWindow = window.open("", "_blank");
        setTimeout(() => {
          linkWindow.location.href="https://google.com"
        }, 2000)
      }
    </script>
  </head>
  <body>
    <div id="root">
      <button onclick="onClick()">
        click me
      </button>
    </div>
  </body>
</html>

This works in any browser, but not in electron.
I did a quick search in their issue tracker and couldn't find something relevant.
It might already be fixed in electron > 8.

Cellule picture Cellule on 21 Mar 2020
👀2

Just discovered, that on macOS there is already native Messenger available built by Facebook, switching to that app myself https://apps.apple.com/pl/app/messenger/id1480068668?mt=12

kopach picture kopach on 29 Mar 2020
🎉2

The app you referenced @kopach is not available in all countries, including Norway :(

FredrikAugust picture FredrikAugust on 30 Mar 2020
👍3 😕2

@kopach This app available only for
🇦🇺 Australia
🇫🇷 France
🇲🇽 Mexico
🇳🇿 New Zealand
🇵🇱 Poland

deril picture deril on 30 Mar 2020

@kopach This app available only for
🇦🇺 Australia
🇫🇷 France
🇲🇽 Mexico
🇳🇿 New Zealand
🇵🇱 Poland

But why?
Okay I found why

If someone wants to try the official app, I uploaded it here

1nikolas picture 1nikolas on 30 Mar 2020

If you don't need Dark Mode, 2.39.0 is the way to go at the moment. It is very stable, at least from my own experience. To avoid auto-update on macOS, just rename the app to something else, e.g. _Caprine 2.39.app_. Can't speak for other platforms though.

Literally can't even install 2.39.0 anymore. No idea what's going on with the installer but it just gets stuck on "installing, please wait..." whereas the installer for 2.44.0 is fine. Don't know why there's no
option to disable auto-update.

xChickens picture xChickens on 30 Mar 2020

Just discovered, that on macOS there is already native Messenger available built by Facebook, switching to that app myself apps.apple.com/pl/app/messenger/id1480068668?mt=12

After some time using official app – I would prefer switching back to Caprine, which is IMHO more functional and easy to use, if this ticket get solved. The only issue with Caprine for me now - not working calls :/

kopach picture kopach on 1 Apr 2020

Just discovered, that on macOS there is already native Messenger available built by Facebook, switching to that app myself apps.apple.com/pl/app/messenger/id1480068668?mt=12

After some time using official app – I would prefer switching back to Caprine, which is IMHO more functional and easy to use, if this ticket get solved. The only issue with Caprine for me now - not working calls :/

The problem with Caprine is that it uses the web interface. The official app works like the mobile app; it uses a database to store messages and thus it loads faster and its less laggier/more responsive. This is not something Caprine can do (unless someone digs through messenger's api and use that), so it's not as good as the official.. (I'm not telling that Caprine is not good, Caprine is as good as it can be but it can't be as good as the original)
Keep in mind that the official app is essentially in beta (that's why they've rolled it out in specific countries)

1nikolas picture 1nikolas on 1 Apr 2020
👍1

The same on Linux, Caprine 2.44.0 (appimage).

lashkevi picture lashkevi on 1 Apr 2020

The same on Linux, Caprine 2.44.0 (appimage).

Everyone should have this problem. Facebook changed something in Messenger that broke Caprine

1nikolas picture 1nikolas on 1 Apr 2020

The same on Linux, Caprine 2.44.0 (appimage).

Everyone should have this problem. Facebook changed something in Messenger that broke Caprine
On Caprine 2.39.0 the calls work. But on Linux it has a damn bad way to toggle from the systray.

lashkevi picture lashkevi on 1 Apr 2020

Well, now it's on Windows too if anyone wants to try
https://about.fb.com/news/2020/04/messenger-desktop-app/

1nikolas picture 1nikolas on 3 Apr 2020

Official App is available on the Mac App Store too.
Seems to be worldwide this time.

raphtabe picture raphtabe on 3 Apr 2020
👍2

Same for me. KDE-Neon and .deb package. Video and calls not working, only white blank page.

swiatlyk picture swiatlyk on 4 Apr 2020

The next text is outdated, see update below

I have resolved this on my local testing electron app (Calls doesn't work there either.)
A basic electron app with app.loadURL("https://www.messenger.com") - it works there.

As @Cellule pointed out, there is some inconsistency (pretty big it seems) between electron's window.open and normal browser's so supporting 3rd party websites with their use of these APIs will be hard.

The problem is in that, when trying to open a new call, Messenger's scripts are trying to open a blank window (we can see that) and then further in, the new url location of that window is set.

Something like this (their code is obfuscated)

h = window.open("", "Group Call", "some other params");
h.location = k; // where k is a path looking like "/groupcall/lots/of/other/params"

Now, it seems this usage is completely incompatible with Electron. Normal browser would handle this and prefix the new location with your current hostname if you don't provide one in .open or in the new location itself.

For example doing the same on electron but without passing any args (just .open() ) and then, If the location I try to set isn't full URL with protocol and hostname (https://www.messenger.com/my/new/path instead of just /my/new/path) it reliably fails, unable to parse the URL.

Compared, on my Firefox it works as it is probably widely expected and that is, if you pass only new path, your current's window proto+hostname+path is automatically used as base for that path. So If I do this in a window with current location https://test.com/path then opening a new window and setting the location on it to /groupcall should result in loading https://test.com/path/groupcall. This is probably what Messenger script's expect.

For now I've resovled this using Proxys and hooking into the window opening to prefix the proto+host before any window location. For now I've been doing this in the Electron's preload.js, when I tried to apply this to Caprine the hooks were not propagated, which is caused by that contextIsolation: true setting for preload scripts and it might not be a good idea to turn that off (if you don't want some scripts having direct access to your data). Unluckily something is still broken even after disabling some of these. So I was unable to apply these hacks to Caprine.

I wrote all of the above yesterday and I will keep it there just for the "documentation" sake.

So, today I found out there is a Electron webcontent's setting that allows the window.location behavior to work like Chrome: nativeWindowOpen. Which is cool because it solves all of the above, at least in simple Electron app.

But, with Caprine this isn't that easy as there is a bit of logic around window-open event in index.ts (privacy logic too), this all might as well break it.

For example, without also setting allowpopups on the root webview, all new-window events now have url of about:blank#blocked instead of just about:blank, there are more differences and I just don't think it's worth it, it could break the current window-open url control.

TLDR

  • Doing newWindow.location = "/path" fails because at it seems, by default electron is trying to join the new-window's location (that window's window.location) with the new location (/path), but the new-window doesn't have valid location.href because it wasn't opened with one.
    w1 = window.open() // w1.location.href === "about:blank"
    In normal browser, as long as your new location is not valid URL on it's own (?) it would join the new path with current's window (the window from where you are opening the new-window) location, not the new-window's one.

Solutions

  • When open of Group Calls window is detected, additionally pre-set the location to https://www.messenger.com.
  • Leverage nativeWindowOpen

Edit: added nativeWindowOpen as another possible solution

wereii picture wereii on 6 Apr 2020
❤3 👍3
Was this page helpful?
0 / 5 - 0 ratings

Related issues

ChristianKlee picture ChristianKlee  ·  4Comments
Martina-Neumayer picture Martina-Neumayer  ·  4Comments
sindresorhus picture sindresorhus  ·  4Comments
willashley23 picture willashley23  ·  3Comments
charlwillia6 picture charlwillia6  ·  4Comments