Bug 687736 – kde-plasma/plasma-browser-integration with www-client/firefox-bin on profile 17.1 - "Failed to connect to the native host. Make sure the 'plasma-browser-integration' package is installed."

• Status: UNCONFIRMED
• Product: Gentoo Linux

[Description Laszlo 2019-06-09 19:52:07 UTC]

Created attachment 579330 [details]
emerge --info output

Since upgrading to the 17.1 profile, KDE browser integration for Firefox is throwing the error popup: 

"Failed to connect to the native host. Make sure the 'plasma-browser-integration' package is installed."

The plasma-browser-integration package is installed and works in other browsers like Chrome.

[Comment 1 Ortwin Glueck 2019-06-12 20:09:16 UTC]

The add-on is looking in /usr/lib:
[pid 14815] openat(AT_FDCWD, "/usr/lib/mozilla/native-messaging-hosts/org.kde.plasma.browser_integration.json", O_RDONLY) = -1 ENOENT (No such file or directory)

But the ebuild put the file in /usr/lib64:
/usr/lib64/mozilla/native-messaging-hosts/org.kde.plasma.browser_integration.json

As this is a json file and not a 64bit so file, the right place is /usr/lib. AS the news item states "/lib and /usr/lib become real directories, that are used for cross-arch and native non-library packages". The bug is therefore in kde-plasma/plasma-browser-integration.

As a silly workaround you can create a symlink to just make it work for now.

[Comment 2 Ortwin Glueck 2019-06-12 20:18:30 UTC]

ln -s /usr/lib64/mozilla /usr/lib/mozilla

[Comment 3 Andreas Sturmlechner 2019-06-12 20:20:05 UTC]

Are you using firefox-bin or firefox? At least for the latter, the current path set by plasma-browser-integration is correct on my system.

It is exactly when I set the path to /usr/lib/mozilla, that I get the error message as described.

[Comment 4 Ortwin Glueck 2019-06-12 20:30:43 UTC]

I should mention that I at least was using firefox-bin

[Comment 5 Andreas Sturmlechner 2019-06-12 20:47:30 UTC]

(In reply to laszlo.erdoes from comment #0)
> works in other browsers like Chrome.
^ with that in mind I'd say we've set the right path. I guess firefox-bin users are simply out of luck?

[Comment 6 Ortwin Glueck 2019-06-12 21:06:54 UTC]

(In reply to Andreas Sturmlechner from comment #5)
> (In reply to laszlo.erdoes from comment #0)
> > works in other browsers like Chrome.
> ^ with that in mind I'd say we've set the right path. 

Because Chrome's files live in /etc and are not affected by the lib/lib64 relocation:
/etc/chromium/native-messaging-hosts/org.kde.plasma.browser_integration.json

I wonder why the difference between firefox-bin and firefox. Maybe firefox-bin could install the symlink? It's a cludge though, I know.

[Comment 7 Jory A. Pratt 2019-06-13 00:19:28 UTC]

(In reply to Ortwin Glueck from comment #6)
> (In reply to Andreas Sturmlechner from comment #5)
> > (In reply to laszlo.erdoes from comment #0)
> > > works in other browsers like Chrome.
> > ^ with that in mind I'd say we've set the right path. 
> 
> Because Chrome's files live in /etc and are not affected by the lib/lib64
> relocation:
> /etc/chromium/native-messaging-hosts/org.kde.plasma.browser_integration.json
> 
> I wonder why the difference between firefox-bin and firefox. Maybe
> firefox-bin could install the symlink? It's a cludge though, I know.

The difference is the bin package is provided by mozilla themselves. We do not build it and have no plans to build -bin packages for mozilla packages. The source build was patches to be multilib aware

[Comment 8 Ortwin Glueck 2019-06-13 06:56:26 UTC]

Interestingly when I install FF directly from Mozilla without using an ebuild, it looks in /usr/lib:

[pid  4369] openat(AT_FDCWD, "/usr/lib/mozilla/native-messaging-hosts/org.kde.plasma.browser_integration.json", O_RDONLY) = 151


I used strace:
 strace -e trace=%file -f firefox 2>&1 |grep plasma

[Comment 9 Ortwin Glueck 2019-06-13 07:00:05 UTC]

Same as firefox-bin of course that is. So 17.1 profile breaks a top Browser binary distribution with an important add-on. What's the idea?

[Comment 10 Ortwin Glueck 2019-06-13 12:18:40 UTC]

Mozilla's statement on the correct location isn't helpful either:

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_manifests#Linux

But it is definitely *not* checking /usr/lib64.

[Comment 11 Ortwin Glueck 2019-06-13 12:29:10 UTC]

It looks only in one of those dirs. Dependent on a constant that is defined at compile time:
https://github.com/mozilla/gecko-dev/blob/e5b695eefd078812ca336f6fdd17df9f1d89f630/toolkit/components/extensions/test/mochitest/test_chrome_native_messaging_paths.html

const libdir = AppConstants.HAVE_USR_LIB64_DIR ? "lib64" : "lib";
      expectGlobal = OS.Path.join("/usr", libdir, "mozilla");

Really Mozilla! Was it that hard to check either path?!?

[Comment 12 Andreas Sturmlechner 2019-06-17 07:55:42 UTC]

(In reply to Jory A. Pratt from comment #7)
> The source build was patches to be multilib aware
Are you positive that is the right thing to do for this directory? If only json files are landing there, then /usr/lib would be correct. If not, then this is a CANTFIX on our side.

[Comment 13 Jory A. Pratt 2019-06-17 14:35:04 UTC]

(In reply to Andreas Sturmlechner from comment #12)
> (In reply to Jory A. Pratt from comment #7)
> > The source build was patches to be multilib aware
> Are you positive that is the right thing to do for this directory? If only
> json files are landing there, then /usr/lib would be correct. If not, then
> this is a CANTFIX on our side.

The ebuild can be updated to use the default /usr/lib/mozilla even source builds are fine with the default location now days as we drop'd the plugin patch a while ago.

[Comment 14 Jory A. Pratt 2019-06-17 18:22:34 UTC]

(In reply to Ortwin Glueck from comment #10)
> Mozilla's statement on the correct location isn't helpful either:
> 
> https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/
> Native_manifests#Linux
> 
> But it is definitely *not* checking /usr/lib64.

Actually it does, but as I will show you why it fails is another issue.

diff --git a/www-client/firefox/firefox-68.0_beta10.ebuild b/www-client/firefox/firefox-68.0_beta10.ebuild
index 99108fa..7a0d52a 100644
--- a/www-client/firefox/firefox-68.0_beta10.ebuild
+++ b/www-client/firefox/firefox-68.0_beta10.ebuild
@@ -276,12 +276,6 @@ src_prepare() {
 		|| die "sed failed to drop --as-needed for ia64"
 	fi
 
-	# Ensure that our plugins dir is enabled as default
-	sed -i -e "s:/usr/lib/mozilla/plugins:/usr/lib/nsbrowser/plugins:" \
-		"${S}"/xpcom/io/nsAppFileLocationProvider.cpp || die "sed failed to replace plugin path for 32bit!"
-	sed -i -e "s:/usr/lib64/mozilla/plugins:/usr/lib64/nsbrowser/plugins:" \
-		"${S}"/xpcom/io/nsAppFileLocationProvider.cpp || die "sed failed to replace plugin path for 64bit!"
-
 	# Fix sandbox violations during make clean, bug 372817
 	sed -e "s:\(/no-such-file\):${T}\1:g" \
 		-i "${S}"/config/rules.mk \


As you can see the source builds are currently using nsbrowser and not the mozilla directory. I am in favor of dropping back to the default that mozilla has defined, so modify your ebuild locally to test that deleting the sed lines will result in a working setup.

[Comment 15 Andreas Sturmlechner 2019-07-24 23:36:03 UTC]

(In reply to Jory A. Pratt from comment #14)
> As you can see the source builds are currently using nsbrowser and not the
> mozilla directory. I am in favor of dropping back to the default that
> mozilla has defined

You say that, but our package had already installed into /usr/$(get_libdir)/mozilla all that time - and it worked with www-client/firefox. Likewise, I see that you dropped those lines in >=68.0, however there is no change to observe after that. plasma-browser-integration continues to install into /usr/$(get_libdir)/mozilla which works for us, while /usr/lib/mozilla does not.

[Comment 16 Victor Mataré 2019-12-16 13:13:01 UTC]

Seems to me that BOTH /usr/lib and /usr/lib64 are the wrong place to put this file. It's clearly architecture independent, isn't it? So it should go below /usr/share and the whole problem goes away. That would make it a Firefox bug, too, but that seems like the correct solution to me.

[Comment 17 Ran Rutenberg 2022-10-09 01:12:50 UTC]

The bug is still relevant for firefox-bin as of today (firefox-bin 105.0.3) and creating the symlink does work.