Mozilla's been hostile to KDE for a long time, and they refuse (for once) to do what Chrome has done and make their browser work with Plasma "out of the box." A freshly installed Chromium variant will use the KDE load and save dialogs without any fuss when running on Plasma, but Firefox stubbornly inflicts the awful GTK file picker on everyone.

Now we've got the option of using XDG desktop portal, which I believe Neon enables by default for Firefox (by means of a short script in /usr/sbin), but that's not a complete solution.

Using Firefox with the portal, the preview panel on the right of the save dialog does not appear. The checkbox in Options for enabling the preview panel is grayed out, and so is the "automatically choose filename extension" checkbox. It's necessary to set the file filter to All files to re-enable the checkbox, then to check the box, each time you save a file. Having the preview is important when working with images, and it should not take that many steps to get it to work each time.

I have also noticed that Firefox freezes for several seconds after saving a file (to a directory with a lot of files) with the desktop portal in use, like it's finishing the enumeration and sorting in the file save dialog, even though it's closed, before it will return control to Firefox. It does that every single time.

OpenSUSE, as I am sure you know, created a patch to better integrate Firefox with KDE/Plasma years ago. The Firefox that comes preinstalled on OpenSUSE and that resides within their repo is the patched version, and it has been for some time, and I am sure they would have pulled it or at least made it an option rather than the only version they offer if it was a problem.

It's not the ideal solution (it needs a small helper program to make it fully work, which is kind of klunky), but it is better than what you get with the desktop portal. Firefox refuses to play nice with Plasma, and I don't think Canonical is willing to bend at all either, but they're coming from a GNOME-is-king mindset (as is Red Hat).

Neon, though, is all about KDE, and the best KDE experience with Firefox is with the OpenSUSE patched version. As such, it would make a lot of sense to make a Firefox version with the OpenSUSE patches available in the Neon repo. That way, those who want the unpatched Firefox could still get it from the Ubuntu repo that is already used for Neon, by installing the standard 'firefox' package, and the rest can have the Firefox experience on Plasma that Mozilla should have offered. OpenSUSE already maintains the patch, so it would not be too hard to do.

At present, I have taken to downloading the .RPM binary from OpenSUSE and installing it either by first converting it to .deb with alien, or else just using Ark and extracting it directly. I also converted the kmozillahelper package to .deb with alien and installed that. Now Firefox works seamlessly with Plasma, with everything in the save dialog working. That's as it should be for KDE!

I would also like to see this. It would make Firefox more of a first class citizen. I'm guessing most people are using Chrome these days in KDEland

Ah, I'd forgotten about the OpenSuse patched Firefox.

At present, I have taken to downloading the .RPM binary from OpenSUSE and installing it either by first converting it to .deb with alien, or else just using Ark and extracting it directly. I also converted the kmozillahelper package to .deb with alien and installed that. Now Firefox works seamlessly with Plasma, with everything in the save dialog working.

I would be interested in getting links to the two items - the Firefox rpm binary and kmozilla for downloading, converting and installing.
Also when you say you used Ark to extract the contents of the rpm - how then do you install?
Or do you run an executable from the extracted contents?

Any information gratefully received and acted upon,

hugh

Here is how it is done in the Arch User Repository:
https://aur.archlinux.org/cgit/aur.git/ ... e-opensuse

Note that when I tried to run it on my laptop, I overheated and crashed.

mparillo wrote:Here is how it is done in the Arch User Repository:
https://aur.archlinux.org/cgit/aur.git/ ... e-opensuse

Note that when I tried to run it on my laptop, I overheated and crashed.

Thanks for the response. I have built stuff from the AUR before but only when I had an arch install.
Also I would be concerned that your laptop darn near caught fire. This would also stop me trying to build an rpm for neon.

Since I posted my request I visited OpenSuse's software search and found a Tumbleweed Firefox branded rpm which seemed up to date - 83.x
I downloaded and extracted with ARK. I drilled down into the resulting three (3) folders but each was empty.
Abandoned that notion and deleted the rpm and the extracted folders.

I wonder how the OP managed it? Perhaps they will see my request sometime and write a quick how-to.
Here's hoping,
Hugh

I would be interested in getting links to the two items - the Firefox rpm binary and kmozilla for downloading, converting and installing.
Also when you say you used Ark to extract the contents of the rpm - how then do you install?
Or do you run an executable from the extracted contents?

It's not working just yet with FF 93, but here's some more info.

The binary RPM from OpenSUSE is from the "MozillaFirefox" package. This is the link that I used at present:
https://software.opensuse.org/package/MozillaFirefox

Kmozillahelper:
https://software.opensuse.org/package/kmozillahelper

The one I use for Neon is in the Leap 15.1 or 15.2 (experimental version in Firefox, since the normal distro version is FF ESR). I try to use the latest one that will work in Neon... Tumbleweed doesn't work, as it relies on libraries that are newer than those in Neon. If Firefox does not run after all of this, run it from the command line and it will tell you what the issue is.

If you want to use ESR, of course, just use the corresponding version on the OpenSUSE site. Be sure to do "expert download" and "grab packages directly" when prompted, and get the .rpm that does not have .src. in it (that is the source code).

The caveat to all of this is that with version 93, Mozilla did something really weird. When Firefox is running, there's no 'firefox' process present on the system! Pretty much every other program has at least one persistent process that is the same as the program name, in Windows or Linux, but not anymore with FF. It's now called GeckoMain. I don't know if that is the reason, but the KDE integration is no longer working. My guess is it is looking for a process called "firefox" and it can't find it.

If you use Firefox older than 93, the KDE integration will still work fine (hopefully!).

So now you have two files, the .rpms from OpenSUSE for MozillaFirefox and kmozillahelper.

If 'alien' is not installed, go ahead and grab that from the repo. Then, go to where kmozillahelper's .rpm is located and enter this in the terminal:

sudo alien --scripts kmozillahelper-5.0.5-lp152.1.13.x86_64.rpm

(substitute the actual filename of your .rpm, of course).

It will output a .deb version of kmozillahelper, which can then be installed.

For Mozilla itself, the easiest way I have found is to install the version from the normal repo with the package manager, then use ark to open the MozillaFirefox .rpm. Ark is able to recognize the .rpm format, so browse its contents and extract libxul.so, and place that in the Firefox directory (rename the original to something else first, so you have it on hand in case the new one won't work). That will require root privileges, of course, as the original Firefox lives in /usr/lib/Firefox, a system location.

Once that file is replaced, the browser integration should hopefully work with no further steps for Firefox versions prior to 93. Kmozillahelper should start by itself when needed (or at least it does on my system). It does not self-start with Firefox 93, but even when I run it manually, it still won't work.

I don't know why Mozilla has been so hostile to KDE. They justified their (now) 20 years of neglect by saying that it's only a small percentage of users who use Linux with KDE, so it's not a priority, but somehow Chrome managed, and by extension, every Chromium derivative out there. Normally, "Chrome does it that way" is all Mozilla needs to hear, but not if it benefits KDE users, evidently.

This attitude is at the heart of why Firefox now has about 4% of the browser market, and falling.

I will be moving on from Firefox if the KDE integration stays broken.

It might actually be KDE Plasma 5.23 that is interfering. I rolled back to a Timeshift snap that I took right before updating to 5.23, which also restored Firefox to 92, and it began working again (of course). So then I locked Firefox to version 92 and let the rest update, and it still does not work.

I will have to see what OpenSUSE does. When they integrate Plasma 5.23, they will presumably discover the issue and fix it (If they have not already). I hope.

Could it be, that just plasma-browser-integration-5.23.1 package is buggy?
Edit: Now I see - the above package is only for Chromium...
Edit2: Firefox 93 also does not follow Plasma style and according gtk applications style...

I am not sure what the cause was, but it appears to be fixed now with Neon (Plasma) 5.23.2 and Firefox 94. I downloaded the MozillaFirefox file and followed the same procedure as normal (described above), and it is once again working in Firefox!

I think it was the update to Firefox 94 that did it. I just upgraded to 94 yesterday, but the upgrade to Plasma 5.23.2 was a few days before that. It could have been another update in one of the libraries pushed out by KDE or Ubuntu, though.

Hmm, Firefox 94 is still not following Plasma font size and cursor theme.
When started from console there are a lot of following messages:
Gdk-Message: 16:31:11.399: Unable to load hand2 from the cursor theme
Currently using binary firefox 91.3.0esr from ftp. mozilla.org which does not have these problems.