Closed posita closed 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.
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!
@pizzadude thank you!!
Fixed with @pizzadude's method.
~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.
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.
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.
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.
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!
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:
At this point, I can navigate to
file:///home/user/.net.downloadhelper.coapp-1.6.3
andfile:///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?