aclap-dev / vdhcoapp

Companion application for Video DownloadHelper browser add-on
GNU General Public License v2.0
1.72k stars 280 forks source link

Brave Flatpak Does Not Recognize Companion App #136

Closed posita closed 1 year ago

posita commented 2 years ago

Companion issue to #114 but for Brave (and possibly other Chrome/Chromium browsers).

I have tried to experiment with something akin to https://github.com/mi-g/vdhcoapp/issues/114#issuecomment-1179559534, but with no success. Here's what I tried:

% tar xpvf net.downloadhelper.coapp-1.6.3-1_amd64.tar.gz
% mv net.downloadhelper.coapp-1.6.3 ~/.net.downloadhelper.coapp-1.6.3
% ~/.net.downloadhelper.coapp-1.6.3/bin/net.downloadhelper.coapp-linux-64 install --user  # creates configs in ~/.config/google-chrome
% flatpak override --user --filesystem=~/.net.downloadhelper.coapp-1.6.3:ro --filesystem=~/.config/google-chrome:ro com.brave.Browser
% flatpak ps | grep -i brave
[no output]
% flatpak run com.brave.Browser

At this point, I can navigate to file:///home/user/.net.downloadhelper.coapp-1.6.3 and file:///home/user/.config/google-chrome/NativeMessagingHosts/net.downloadhelper.coapp.json without issue. However, chrome-extension://lmjnegcaeklhafolokijcfjliaokphfk/content/settings.html?panel=settings still shows the companion app as missing.

Any advice?

paulrouget commented 1 year ago

Still no idea how to solve this. Any pointers would be welcome. It seems that Brave-flatpak doesn't offer any persistent volume to store the manifest files.

pizzadude commented 1 year ago

mkdir -p ~/.var/app/com.brave.Browser/config/BraveSoftware/Brave-Browser/NativeMessagingHosts

flatpak override --user --filesystem=~/net.downloadhelper.coapp:ro

save this as net.downloadhelper.coapp.json :

{
    "name": "net.downloadhelper.coapp",
    "description": "Video DownloadHelper companion app",
    "path": "/home/user/net.downloadhelper.coapp/bin/net.downloadhelper.coapp-linux-64",
    "type": "stdio",
    "allowed_origins": [
        "chrome-extension://lmjnegcaeklhafolokijcfjliaokphfk/",
        "chrome-extension://nfpjjpkpalipnaioacmoppfnajcipame/"
    ]
}

change the paths if needed

put it in ~/.var/app/com.brave.Browser/config/BraveSoftware/Brave-Browser/NativeMessagingHosts directory you just created

???

profit!

paulrouget commented 1 year ago

@pizzadude thank you!!

paulrouget commented 1 year ago

Fixed with @pizzadude's method.

posita commented 1 year ago

~This is a work-around, and (as far as I can tell) it's undocumented except here. I don't think that would meet the criteria of "fixed". It means that every user encountering this problem would have to know to come here, and would have to follow some fairly technical instructions to get this to work. I think this should be reopened to accommodate the default install locations.~ UPDATE: Because no fix was linked, I was confused that this issue was closed as if @pizzadude's https://github.com/aclap-dev/vdhcoapp/issues/136#issuecomment-1716714551 was being treated as the fix. I didn't realize that 7e8d7f60e328f3f3dad9f8c446f144b000b779d9 actually worked the technique into the installer. However, the VDH install page probably needs to be updated, too? (VDH, despite it's claims of trustworthiness is relatively opaque, so I'm not clear on how that happens.

posita commented 1 year ago

UPDATE: I think this is addressed by 7e8d7f60e328f3f3dad9f8c446f144b000b779d9 as well, since the overridden path is derived from the install location of the helper app. The original (obsoleted) comment is retained below.


While not as accessible as what I'm advocating for in my prior https://github.com/aclap-dev/vdhcoapp/issues/136#issuecomment-1717686823, for those with the .deb install, this works (from the host, not from within the flatpak execution environment):

#!/usr/bin/env sh
flatpak override --user --filesystem=/opt/net.downloadhelper.coapp:ro com.brave.Browser
mkdir -p "${HOME}/.var/app/com.brave.Browser/config/BraveSoftware/Brave-Browser/NativeMessagingHosts"
cp /etc/chromium/native-messaging-hosts/net.downloadhelper.coapp.json \
    "${HOME}/.var/app/com.brave.Browser/config/BraveSoftware/Brave-Browser/NativeMessagingHosts"

I don't know enough about Brave/Chromium to know if there's a better approach here.

Note that exposing subdirectories of /etc in flatpak is hard (and largely considered unworkable). However, within the flatpak, /etc/chromium is available via /var/run/host:

% flatpak run --command=ls com.brave.Browser /etc/chromium/native-messaging-hosts
ls: cannot access '/etc/chromium/native-messaging-hosts': No such file or directory
% flatpak run --command=ls com.brave.Browser /var/run/host/etc/chromium/native-messaging-hosts
net.downloadhelper.coapp.json  org.gnome.chrome_gnome_shell.json

I'm not sure what (if any) opportunities that observation affords?

For the tarball installations, #56 needs to be reopened and addressed for reasonable progress to be made for those techniques.

posita commented 1 year ago

I see that steps were made in 7e8d7f60e328f3f3dad9f8c446f144b000b779d9, but this issue wasn't referenced, so my previous https://github.com/aclap-dev/vdhcoapp/issues/136#issuecomment-1717686823 may no longer be relevant. Still, #56 needs to be reopened and addressed. Silently installing files into various locations is super creepy.

paulrouget commented 1 year ago

Silently installing files into various locations is super creepy.

It's not anymore (in master). All the created files are being reported in stdout.

Please be patient, we are working on a new version of the coapp (you've seen the commit) but it's not released yet.

posita commented 1 year ago

Silently installing files into various locations is super creepy.

It's not anymore (in master). All the created files are being reported in stdout.

Ah! Brilliant! I didn't realize. I thought #56 was closed without at fix.

Please be patient, we are working on a new version of the coapp (you've seen the commit) but it's not released yet.

Understood. Surfacing methods and behaviors meant to address issues in surfaces likely encountered by folks experiencing those issues is an art, to be certain. Thanks for the clarity!