Open Bug 1659361 Opened 5 years ago Updated 1 year ago

Desktop integration: 64-bit Firefox doesn't find 64-bit native messaging hosts

Categories

(WebExtensions :: General, enhancement, P3)

Product:
WebExtensions
Component:
General
Version:
79 Branch
Platform:
x86_64
Linux
Type:
enhancement

Tracking

(Not tracked)

Status:
UNCONFIRMED

People

(Reporter: rover.bugfinder, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Linux 64-bit, Firefox 79.0 64-bit (downloaded from Mozilla, not installed using the distribution's packaging system), KDE desktop, plasma-browser-integration package installed.
I install the "Plasma Integration" extension/addon to integrate the browser with the desktop.

Actual results:

Addon installed successfully, but it reports that it can't connect to the native host.
The plasma-browser-integration package installs its json file in /usr/lib64/mozilla/native-messaging-hosts/org.kde.plasma.browser_integration.json, but apparently Firefox is not looking there.
Symlinking .mozilla/native-messaging-hosts -> /usr/lib64/mozilla/native-messaging-hosts and restarting Firefox helps.
Symlinking /usr/lib/mozilla -> /usr/lib64/mozilla (as root) and restarting Firefox also helps.
This is a minor issue in case of this addon, but it still can disappoint some users.
This could be a more serious issue in case of other addons.
Works out-fo-the-box with Chromium.
Reproducible: always. Just delete and re-create the symbolic links as necessary.

Expected results:

Addon can connect to the native host without any need for manual user actions.
I guess that adding /usr/lib64/mozilla to native host configuration search paths would solve the problem.

OS: Unspecified → Linux
Hardware: Unspecified → x86_64

Additional small comment: I didn't look at the source code, but the binary libxul.so contains the strings: "/usr/lib64", "/usr/lib" (without trailing slashes) and "/usr/lib/", but it doesn't contain "/usr/lib64/" (with a trailing slash). This probably adds a point to the suggestion of extending the search paths.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

Hi rover,

Is this the extension you are referring to? https://addons.mozilla.org/es/firefox/addon/plasma-integration/

This issue was moved over to Widget: Gtk so developers can take a look over it.
Thanks for the report.

Best regards, Clara.

Hi.

Yes, that's the extension. Thank you for taking a look at my report. The product and the list of components are both so complex that it's hard to select the correct one.

Best regards, RB.

This should be reported at https://bugs.kde.org/ as the plasma integration is developed by KDE.

Hi.
I'm not convinced about that it's a KDE bug.
I understand that KDE developers are developing the plasma integration EXTENSION.
But Mozilla is developing the NATIVE MESSAGING in Firefox and I believe that this is the part that could be improved.
I didn't look at any code, but I think that KDE's extension just looks at what messaging hosts Firefox provides and I believe the problem is that Firefox doesn't provide the needed data. It's a matter of looking at just one more path in the system. I don't think that extensions e.g read the Windows registry or browse the filesystem to find the right path, I think the browser does this part.
See the bottom table on https://wiki.mozilla.org/WebExtensions/Native_Messaging and also see http://devdoc.net/web/developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging.html#Linux. From what I understand, both /usr/lib and /usr/lib64 (or maybe all 3: /usr/lib, /usr/lib64 and /usr/share) should work. Well, at least /usr/lib64 doesn't and I need the workaround linking ~/.mozilla/native-messaging-hosts to /usr/lib64/mozilla/native-messaging-hosts.
I hope I cleared things up a bit. If this brings new information, then perhaps the classification (Product/Component) needs to be changed, but I'm too new to classify correctly.
Thank you.

We get to the lib path via NativeManifests.jsm. We finally end up calling GetSystemParentDirectory. That function has an ifdef HAVE_USR_LIB64_DIR. For me on a 64bit Firefox Nightly build this is false. So we end up using /usr/lib/mozilla instead of /usr/lib/mozilla64.

Mike, any idea here? Shouldn't be HAVE_USR_LIB64_DIR set on 64-bit systems?
Thanks.

Flags: needinfo?(mh+mozilla)
Priority: -- → P3

btw. I see this construction is used to set the HAVE_USR_LIB64_DIR:

if CONFIG['OS_ARCH'] == 'Linux' and 'lib64' in CONFIG['libdir']:
DEFINES['HAVE_USR_LIB64_DIR'] = True

I'm not sure what CONFIG['libdir'] means, is that the --libdir mozconfig param?

I think fixing this by having this method return just /usr/lib64/mozilla might not be the best solution. Considering that probably a lot of users are on a 64bit OS and are currently using the old path /usr/lib/mozilla, just changing to lib64 would break native messaging for them. Instead I would suggest hard coding these two paths in the JSM.

We should make this thing work based on what's available at runtime, not at compile time. If anything, Mozilla builds of Firefox are not looking in /usr/lib64/mozilla.

Flags: needinfo?(mh+mozilla)

Perhaps 32-bit Firefox builds should look in /usr/lib/mozilla (and /usr/share/mozilla as the wiki says?), since they won't be able to load 64-bit binaries anyway (I think) and 64-bit Firefox builds should look in /usr/lib/mozilla (for compatibility) and /usr/lib64/mozilla (and /usr/share/mozilla, as previously?), with both /usr/lib/mozilla and /usr/lib64/mozilla hardcoded?
Right, we don't know if e.g. 32-bit Firefox won't be run on a 64-bit system, but, as I wrote, maybe it wouldn't be able to use 64-binaries.
On the other hand, "bitness"-incompatible (32/64) binaries probably can't be loaded in neither build, so maybe all of /usr/lib/mozilla, /usr/lib64/mozilla and /usr/share/mozilla should be hardcoded in all builds anyway, and the browser would load all compatible providers from all paths available at runtime ("compatible" meaning either architecture-independent, if at all possible, or those which the OS allows to load, e.g. .so/.dll).

Based on my reading, this needs to be fixed in the Extension support code.

Component: Widget: Gtk → General
Product: Core → WebExtensions

Comment 12 suggestion sounds good, though is a corner case so not a high priority for. Patches welcome!

Severity: -- → N/A
Type: defect → enhancement
You need to log in before you can comment on or make changes to this bug.