Firefox runs without interface

Support Software & Applications
62

Something that seems to be working for me that everyone might want to try. I’ve been waiting a few minutes after booting my system before opening FF. Not sure if it’s a coincidence or what, but so far it’s worked for me.

63

OK, @tempest2084. I tested to wait for some time.
By accident, it became around half an hour.
But, Firefox started on first attempt, though.
/ Hans Gatu

64

Same problem for me after the last update (20-12-22) and reboot.
The solution I used last times was :
firefox --new-window about:support (+ Clear Start cache)
but without effect today.

What worked this time is :

  • open Task Manager and enter firefox in selection area
  • kill the FF process with highest PID number
  • possibly repeat on the second one
  • FF opens with all the tabs …
65

Now Firefox works. It starts at first attempt. Everything looks just fine.
It all happened yesterday, after Manjaro big update that (among plenty of other package updates) included updated Firefox and updated kernel.

/ Hans Gatu

66

He doesn’t believe it. It could be a coincidence. I don’t know what manjaro updated in this update but on arch it doesn’t continue to work.
Looking at the packages it firefox still hasn’t gotten the update since 16
Mesa hasn’t either
It’s either they came up with a workaround or it will be something else
Arch gets updates faster than manjaro so I really don’t know why it still works the way it does
But I’ll believe it when I see a clean manjaro after installation with ff running

67

Well. Tried latest updates … [Stable Update] 2022-12-20 - Kernels, XFCE 4.18, KDE Frameworks, Kde Gear, Mesa, Plasma-Mobile, Thunderbird, Firefox. Update itself went without problems.

But situation around mesa higher than 22.1.7 causing trouble for Firefox startup persist.

  • So we are lucky and still have packages from 22.1.7 version of mesa and we can downgrade to this version of ?-mesa-?, ?-vulkan-? packages. (or other version that worked for you).
  • Or endure, go along with upgrades and manually kill highest PID of Firefox to let it continue.

As I read this is unrelated to removal of video codecs from open source AMD graphic mesa driver (22.3+). Since my trouble started at start of november already. And that is moving from mesa version 22.1.7.

68

Its not problem with radeon vulkan package because i don’t use it cuz i’m using radeon instead of amdgpu.
Try remove libva-mesa-driver and mesa-vdpau it should help i think. These packages problems recently caused my firefox to behave like this

69

wake up people.
The mesa update for the 31.12 arch still does not fix the problem.
I played around and check for yourself if you have pipewire-pulse installed.
When I uploaded it the first time after a reboot the browser launched but that’s probably just luck

70

Another mesa update for arch still firefox not fixed

71

Yeah. For me … keeping mesa and vulkan packages back at 22.1.7 solved everything with starting Firefox. But I actually started using Manjaro in august 2022. So I have 22.1.7 version of mesa from that installation.

There is no VA-API error with this old version and looking at:

It seems more and more changes are still happening. So probably in future some mesa, vulkan and firefox might just again work with one another and will use hardware acceleration using VA-API without errors. Unless these will get entirely replaced with something else.

This happens only when we are talking physical and accessible AMD graphic cards, since in virtual machines I never got any problems with Firefox. Either way “Big companies” messing around with open source drivers and video decoders/encoders at least does explain current problems. It will take time, before Mozilla can repair their hardware acceleration to whatever will be used for new video decoder/encoder.

At least that is how I understand current situation.

72

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?

73

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. :sweat:

74

Hi!
same bug with a liveusb:

    1. launch manjaro-kde-22.0.1-230124-linux61.iso
    1. click on the firefox icon
    1. and … nothing happens!

This bug does not occur on Fedora, Ubuntu, …

75

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.

76

I now have the same bug with fedora ? ?

77

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. :confused: Managed to launch FF by killing the last child process of Firefox, as it was written earlier.

78

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.

79

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.

80

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)

  • llvm 15.0.7-1 => 14.0.6-4 and also llvm-libs lib32-llvm-libs (and other llvm packages if any)
  • clang 15.0.7-1 => 14.0.6-4
  • compiler 15.0.7-1 => 14.0.6-4 and also
  • shiboken6 6.4.2-5 => 6.4.1-2
  • pyside6 6.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.

1 Like
81

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 !