Firefox had been working perfectly up until I updated this morning and now it’s back to not starting unless I kill it several times and I get that safe mode prompt. Did they revert something?
With this upgrade ([Stable Update] 2023-01-24 - Kernels, Plasma, Frameworks, Gear, Libreoffice, Mesa, Nvidia, Deepin) I can’t downgrade to mesa 22.1.7 … because new KDE release becomes software rendered.
Now there is no way to avoid this quirky Firefox startup anymore. 
Hi!
same bug with a liveusb:
-
- launch manjaro-kde-22.0.1-230124-linux61.iso
-
- click on the firefox icon
-
- and … nothing happens!
This bug does not occur on Fedora, Ubuntu, …
I’ve had it happen on my Ubuntu laptop. But I don’t reboot that laptop very often so it doesn’t cause me nearly as much trouble.
I now have the same bug with fedora ? ?
Wanted to write about the same on my openSuse installation yesterday and mention that with Manjaro everything was intakt. But today faced this bug on my Manjaro i3. 
Managed to launch FF by killing the last child process of Firefox, as it was written earlier.
I guess it would be better if the ones with the issue could bring something more than “it is broken again”. Maybe try to see if you have relevant logs, if enabling/disabling some features like hardware acceleration helps, giving your system information, things like that.
It is apparently a “niche” issue as it is not widespread on all systems, so for better understanding and resolution, share the maximum information.
The only thing that seems to work for me is waiting a few minutes after boot up to open firefox. That seems to work without fail. I’m not sure what that implies as the problem though.
We still can go to version of mesa that does have hardware acceleration in Firefox, SMPlayer and works stable for us before all these problems hit AMD GPU users.
A seriously big thanks to @AddiejeWoah for
Showed me the way. First you downgrade existing installed qt6-x packages from 6.4.2-3 => 6.4.1-1.
Then you go after installed qt5-x packages and downgrade them 5.15.8-1 => 5.15.7-1.
Then since mesa works with llvm and clang we also need to downgrade these (if they are installed on your system)
-
llvm15.0.7-1 => 14.0.6-4 and alsollvm-libslib32-llvm-libs(and otherllvmpackages if any) -
clang15.0.7-1 => 14.0.6-4 -
compiler15.0.7-1 => 14.0.6-4 and also -
shiboken66.4.2-5 => 6.4.1-2 -
pyside66.4.2-5 => 6.4.1-2
Then as the last step you go after mesa and vulkan … Downgrading just mesa basically breaks KDE desktop and causes it to be software rendered (can’t detect OpenGL).
But seriously on my system that is already 39 packages to downgrade once or twice per every month. If I want hassle free running of Firefox, h264 acceleration and KDE working stable on my comp.
It’s a bit over 4 months since I started using Manjaro … but this is making me reconsider rolling release model.
Even in older days I remember on Kubuntu my Sapphire R9 290 TRI-X was brand new, but amdgpu, also amdgpu-pro caused a desktop to just randomly crash to black screen … And same happened in Windows. But if I wanted to watch video without constant freezes I had to install amdgpu-pro proprietary drivers. But then a new LTS of Kubuntu came I reinstalled old one and it was stable to use. On Win I could simply pick some older Crimson Re-live driver and black screen issue went away…
But Manjaro is just different kind of cookie to stomach. And I am not sure I like these jumps to new and newer stuff. Fells more like being forced beta tester. But well people still like and buy Tesla-s despite such treatment … If nothing else software is up-to-date, but system packages and drivers is where it hurts.
Hi omano,
The problem is that I found no error … either in journalctl, or by launching FF from Terminal !
With last update from January, I blocked FF update (to 108…), but I still got the problem ! Every day I restart my PC, and only after 3 days, FF properly started without any need to cancel some process with Task Manager.
So the problem is with the update, and I now suspect some process launched after an update that locks some ressources that FF may need. In a post from last updates, someone said that man-db could be in cause, but I did not find any man-db process when FF did not start properly. And FF starts if we kill one of its process, so ???
And also, some users have the problem on other distros !
There was a large Manjaro update today and right after I updated the problem came back. The only way to fix it was to open and kill FF in the terminal several times until FF asked if I wanted to open up in safety mode (or whatever it calls it). Once that window appears you can tell it to open up normally and from then on it’s ok. There’s something majorly screwy going on with FF these days.
1 Like
First of all I open the XFCE activity monitor. Then I start Firefox.
Of some reason, there is always three Firefox instances started.
But, if I immediately kill the third instance, then Firefox start normally.
/ Hans Gatu
That worked for me. What’s the cause of this?
Try to deactivate some of the extensions, close, reopen, … until you get a normally opening FF.
For me, I currently suspect AdBlocker Ultimate that is the only extension I keep deactivated. Il I activate it, FF doesn’t open ! And Adblock (normal one) doesn’t show the problem.
I only have uBlock Origin and that isn’t something I can get rid of
Just deactivate it for a test.
This worked for me, too. It’s identical to the workaround already proposed above by @ff8idiot
I’ve since switched to openSuSE, and Firefox starts up normally there.
For what it’s worth. On this page: https://wiki.mozilla.org/Firefox/CommandLineOptions they say: “Firefox is a GTK app, and as such supports the GTK flags documented here.”
Might provide more insight into the problem.
OK … first I need to report few changes with my system, since I am not sure if they are relevant or not …
- kernel I am running with now is from
linux61line so 6.1.19-1-MANJARO - I gave up on downgrading
mesaand associated packages (Okular couldn’t be started with too oldqt5-xxxpackages, and there are possibly other programs that did start to break, but I don’t use a whole lot of them from KDE Plasma desktop). So now I am at22.3.5-1version ofmesa. - I am running non-free version of
mesa(from https://nonfree.eu/) that supposedly does have video decoding inside. So I expected at least H264 HW flag (Sapphire R9 290 TRI-X is too old for anything else) to be accelerated in Firefox. - Firefox also was regularly upgraded so we are talking 64-bit version
111.0of Firefox here. But solution maybe works for a little older versions too.
So at least on my system as it currently is, “Firefox startup without interface” is solved and I am gonna mark it as such. What solved Firefox startup was just adding an environment variable MOZ_ENABLE_WAYLAND=1 under Firefox shortcut.
Source is [SOLVED] Firefox 99 breaks VAAPI / Applications & Desktop Environments / Arch Linux Forums Basically from Konsole you run Firefox with:
MOZ_ENABLE_WAYLAND=1 firefox %u
And this perfectly starts Firefox from command line. So translating this to KDE Desktop shortcut …
- Right click on Firefox icon
- pick
Edit Application... - under
Applicationtab you will see input field forEnvironment Variables: - I just added
MOZ_ENABLE_WAYLAND=1into it (it was empty before)
Now this does solve startup, but hardware acceleration is entirely different story. Konsole just changes error now to:
[GFX1-]: glxtest: failed to read data from glxtest, we may fallback to software rendering
[GFX1-]: No GPUs detected via PCI
And in pictures it looks my GPU is recognized, since it is indeed from HAWAII family of AMD GPUs, but somehow isn’t “acceptable” to Mozilla Firefox:
Just saying writing this to keep your expectations low on hardware acceleration matter. But at least starting up Firefox was 100% solid after reboot or after just closing Firefox.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.