| Summary: | 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." | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Laszlo <laszlo.erdoes> |
| Component: | Current packages | Assignee: | Gentoo KDE team <kde> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | laszlo.erdoes, me, mozilla, o.freyermuth, odi |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 506276 | ||
| Attachments: | emerge --info output | ||
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. ln -s /usr/lib64/mozilla /usr/lib/mozilla 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. I should mention that I at least was using firefox-bin (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? (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. (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 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 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? 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. 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?!? (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. (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. (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. (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. 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. The bug is still relevant for firefox-bin as of today (firefox-bin 105.0.3) and creating the symlink does work. |
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.