Firefox runs without interface

I also have reason to believe, that it is a Firefox issue.
It behaves exactly the same way for me, even though I explained it differently in my thread:

/ Hans Gatu

I’m pretty sure it is Firefox because if I install Chrome (Chromium) it doesn’t have this issue.

Kernel: 5.15.78-1-MANJARO arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
parameters: BOOT_IMAGE=/boot/vmlinuz-5.15-x86_64
root=UUID=38bf1d9c-d4fd-4d72-b6cb-8407756db8fd ro quiet
Desktop: GNOME v: 43.1 tk: GTK v: 3.24.34 wm: gnome-shell dm: GDM v: 43.0
Distro: Manjaro Linux base: Arch Linux
Type: Desktop Mobo: EVGA model: 141-BL-E757 v: Tylersburg
serial: BIOS: Phoenix v: 6.00 PG date: 08/25/2011
Device-1: hidpp_battery_0 model: Logitech M510 serial:
charge: 55% (should be ignored) rechargeable: yes status: discharging
Info: model: Intel Core i7 920 bits: 64 type: MT MCP arch: Nehalem
gen: core 1 level: v2 built: 2008-10 process: Intel 45nm family: 6
model-id: 0x1A (26) stepping: 5 microcode: 0x1D
Topology: cpus: 1x cores: 4 tpc: 2 threads: 8 smt: enabled cache:
L1: 256 KiB desc: d-4x32 KiB; i-4x32 KiB L2: 1024 KiB desc: 4x256 KiB
L3: 8 MiB desc: 1x8 MiB
Speed (MHz): avg: 1605 high: 1686 min/max: 1596/2661 boost: enabled
scaling: driver: acpi-cpufreq governor: schedutil cores: 1: 1592 2: 1592
3: 1592 4: 1606 5: 1592 6: 1592 7: 1686 8: 1592 bogomips: 42469
Flags: ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3
Type: itlb_multihit status: KVM: VMX unsupported
Type: l1tf mitigation: PTE Inversion
Type: mds status: Vulnerable: Clear CPU buffers attempted, no microcode;
SMT vulnerable
Type: meltdown mitigation: PTI
Type: mmio_stale_data status: Unknown: No mitigations
Type: retbleed status: Not affected
Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via
prctl and seccomp
Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer
Type: spectre_v2 mitigation: Retpolines, IBPB: conditional, IBRS_FW,
STIBP: conditional, RSB filling, PBRSB-eIBRS: Not affected
Type: srbds status: Not affected
Type: tsx_async_abort status: Not affected
Device-1: AMD Cape Verde XT [Radeon HD 7770/8760 / R7 250X] vendor: Hightech
Information System driver: radeon v: kernel alternate: amdgpu arch: GCN-1
code: Southern Islands process: TSMC 28nm built: 2011-20 pcie: gen: 2
speed: 5 GT/s lanes: 16 link-max: gen: 3 speed: 8 GT/s ports:
active: DVI-I-1 empty: DP-1,DP-2,HDMI-A-1 bus-ID: 02:00.0
chip-ID: 1002:683d class-ID: 0300 temp: 37.0 C
Display: x11 server: X.Org v: 21.1.4 with: Xwayland v: 22.1.5
compositor: gnome-shell driver: X: loaded: radeon unloaded: modesetting
alternate: fbdev,vesa dri: radeonsi gpu: radeon display-ID: :0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")
s-diag: 582mm (22.93")
Monitor-1: DVI-I-1 mapped: DVI-0 model: Asus VH242H serial:
built: 2012 res: 1920x1080 hz: 60 dpi: 94 gamma: 1.2
size: 521x293mm (20.51x11.54") diag: 598mm (23.5") ratio: 16:9 modes:
max: 1920x1080 min: 720x400
API: OpenGL Message: Unable to show GL data. Required tool glxinfo
Device-1: Intel 82801JI HD Audio driver: snd_hda_intel v: kernel
bus-ID: 00:1b.0 chip-ID: 8086:3a3e class-ID: 0403
Device-2: AMD Oland/Hainan/Cape Verde/Pitcairn HDMI Audio [Radeon HD 7000
Series] vendor: Hightech Information System driver: snd_hda_intel
v: kernel pcie: gen: 2 speed: 5 GT/s lanes: 16 link-max: gen: 3
speed: 8 GT/s bus-ID: 02:00.1 chip-ID: 1002:aab0 class-ID: 0403
Sound API: ALSA v: k5.15.78-1-MANJARO running: yes
Sound Server-1: JACK v: 1.9.21 running: no
Sound Server-2: PulseAudio v: 16.1 running: yes
Sound Server-3: PipeWire v: 0.3.59 running: yes
Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
driver: r8169 v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: de00
bus-ID: 06:00.0 chip-ID: 10ec:8168 class-ID: 0200
IF: enp6s0 state: up speed: 1000 Mbps duplex: full mac:
Local Storage: total: 1.25 TiB used: 357.36 GiB (28.0%)
SMART Message: Required tool smartctl not installed. Check --recommends
ID-1: /dev/sda maj-min: 8:0 vendor: Western Digital
model: WD5001AALS-00L3B2 size: 465.76 GiB block-size: physical: 512 B
logical: 512 B speed: 1.5 Gb/s type: N/A serial: rev: 3B01
scheme: MBR
ID-2: /dev/sdb maj-min: 8:16 vendor: Kingston model: SA400S37120G
size: 111.79 GiB block-size: physical: 512 B logical: 512 B speed: 3.0 Gb/s
type: SSD serial: rev: 71E0 scheme: MBR
ID-3: /dev/sdc maj-min: 8:32 vendor: Samsung model: SSD 850 EVO 250GB
size: 232.89 GiB block-size: physical: 512 B logical: 512 B speed: 3.0 Gb/s
type: SSD serial: rev: 2B6Q scheme: MBR
ID-4: /dev/sdd maj-min: 8:48 vendor: Samsung model: SSD 860 EVO 500GB
size: 465.76 GiB block-size: physical: 512 B logical: 512 B speed: 3.0 Gb/s
type: SSD serial: rev: 4B6Q
ID-1: / raw-size: 111.79 GiB size: 109.47 GiB (97.93%)
used: 71.96 GiB (65.7%) fs: ext4 dev: /dev/sdb1 maj-min: 8:17
Alert: No swap data was found.
System Temperatures: cpu: 44.0 C mobo: N/A gpu: radeon temp: 37.0 C
Fan Speeds (RPM): N/A
Processes: 270 Uptime: 1h 2m wakeups: 20 Memory: 11.68 GiB
used: 1.94 GiB (16.6%) Init: systemd v: 251 default: graphical
tool: systemctl Compilers: gcc: 12.2.0 clang: 14.0.6 Packages: 1510
pm: pacman pkgs: 1499 libs: 449 tools: gnome-software,pamac pm: flatpak
pkgs: 0 pm: snap pkgs: 11 Shell: Bash v: 5.1.16 running-in: gnome-terminal
inxi: 3.3.23

I just thought that I’d share this little tidbit I found that seems to describe this bug:

So it sounds like it’s an error with libx11 1.8.2. Hopefully it will get fixed soon.

I can confirm the issue described here. Starting Firefox - regardless of whether this is from the menu or from a Konsole command line, regardless of whether it’s the latest version from the repositories, from Snap, or from a download from the Mozilla site - creates 3 instances of firefox-bin visible in the system activity monitor, but without any window. There’s no error message.

Repeated attempts to start Firefox (I had a whole 18 processes “firefox-bin” running at one point earlier today) eventually result in one of these processes turning “zombie”. I don’t know whether this matters, but after this the Firefox dialogue box appears on the screen to tell me that Firefox is already running but not responding. At that point, I can “killall firefox-bin” and start Firefox again. This time a SINGLE “firefox-bin” process is started, and a Firefox window opens in the expected way. Firefox works perfectly after this. Closing the window and starting Firefox again also works as expected. But this lasts only until the next system shutdown and reboot, after which the faulty behaviour described above reappears.

By contrast, as others have explained, simply killing and restarting Firefox doesn’t work reliably.

This is a very annoying problem. Firefox is the only application I use literally every day.

Well as I showed in later post on KDE at least … problem is only with start-up of Firefox … that spawns multiple process identities and all are “Firefox” I can’t tell what exactly these are …

But I can absolutely perfectly resume start-up by killing the last process identity as I have shown on the picture of reply 31 (Firefox runs without interface - #31 by ff8idiot). After that only the first process identity remains and Firefox GUI window frames do spawn. At least on KDE it’s consistent in this start-up behaviour.

But absolutely nothing else helped …

  • downgrade to 105.x (so whatever version expect perhaps very old ones change nothing)
  • upgrade, complete removal and installation of latest version of Firefox also don’t work
  • removing .mozilla configuration under /home/xxx/
  • and exactly same if you rename .mozilla to whatever else so Firefox can’t find files anymore
  • startup from console with any arguments and there is no errors reported at all
  • firefox --new-window about:processes can’t be used for start-up since no GUI (graphic user interface) will spawn and you have nothing to look at.

It’s just that start-up of Firefox that freezes up. After unfreeze with killing the last of Firefox process identities, Firefox just works perfectly as always … with all od my settings and extensions and tabs as I want them and should be.

Killing and restarting all of Firefox processes and re-attempting whole start-up again is just overkill. And even if you do and eventually arrive to this dialog:
You can just hit [Open] to have all the tabs re-opened, since Refresh resolves nothing about start-up. But with [Open] you have all extensions disabled. And as a result you have to re-start Firefox again to have extensions re-enabled … and again chances are start-up problem might just happen all over again … after you perhaps already re-started whole Firefox like 8 … 12 (or even more) times.

So the problem is just mildly annoying, since it requires us to involve ourselves in start-up … But with killing all Firefox processes and re-starting we ourselves are just escalating the problem.

What kind of problem do you have @ff8idiot ?

Nothing that I didn’t report before in perhaps too much details. So this time I will let pictures do the talking:

Trying to run Firefox from GUI (KDE in my case)

Icon is there, loading is visible …

And than nothing … you are watching episode of “Dude where is my Firefox”.

Now to “unfreeze” Firefox startup …

And it worked for me …

Just closing Firefox with Ctrl + Q and confirming with [Close and Quit] put me back into another episode of “Dude, where is my Firefox” after I try to (re)run Firefox again.
I need to mitigate Firefox startup again with

kill $(pgrep firefox | tail -n 1)

But i want you to know this works and I can start Firefox 100%. Hope this helped anyone.

Starting from console this time did show an error though:

[GFX1-]: glxtest: VA-API test failed: process crashed. Please check your VA-API drivers.

Maybe that is the last process identity I killed …

This is the exact issue I have with FF on my Mint xfce install. On Manjaro, it works fine. Go figure.

It’s been hit and miss with this issue for the last few days. Some days i have the issue, but other days FF starts up right away. I’m starting to wonder if on the days I don’t have the issue are those days were I let the computer sit for a few minutes after booting (to go get a coffee or something) instead of starting FF right away. I can’t see why this would make a difference, but other than some other random thing happening, this is the only difference I can see.

Funny enough I upgraded my laptop from the LTS Ubuntu to the latest version last night and now I’m having this exact same problem. To me this says it’s a Firefox issue not a Linux issue unless it’s a common module that both Ubuntu and Manjaro share somehow.

Have you tried what nkgnomic proposes in this thread :

Try this to open a Firefox widow showing Troubleshooting Information page

firefox --new-window about:support

and click on Clear startup cache…

This solution solved for my FF problem

@Denis_Pom I will repeat …

firefox --new-window about:support

Does not even start Firefox … Nor does [Clear Startup Cache] change anything. No matter if I reach to about:support page from console or from already open instance.

It isn’t even Linux distro issue, much less Manjaro’s issue.

Last I checked for actually reported error with
[GFX1-]: glxtest: VA-API test failed: process crashed. Please check your VA-API drivers

It’s problem with AMD drivers that are within mesa (mesa-vdpau) and indeed … mesa was upgraded 22.1.7 => 22.2.x now at beginning of November 2022.

I checked Gitlab changelist for 2022-11-02 Majaro packages upgrade (search for mesa and mesa-vdpau).
Also I know Ubuntu LTS (22.04.1) has mesa at 22.0.x, but latest (22.10) has mesa at 22.2.x. Weirdly enough I have no issues using Lubuntu 22.10 at work, but that one runs as Hyper-V virtual machine so no graphic card.

I downgraded mesa packages back to 2.1.7 and Firefox now started perfectly a few times even after machine reboot … so it seems so far it has worked for me:

sudo downgrade mesa vulkan-radeon vulkan-intel lib32-vulkan-radeon lib32-vulkan-intel libva-mesa-driver lib32-mesa-vdpau lib32-mesa lib32-libva-mesa-driver mesa-vdpau

After reboot of machine it opened Firefox on first try. Also closing and re-opening turned out to be without any problems… so far.

But this is another “can of worms” solution, because mesa and integrated drivers will be inevitably upgraded and shipped with all Linux distributions … so eventually I will have to go along with these upgrades. Or something might just break eventually, since package x and y might become out-of-sync.

There were mesa Radeon driver upgrades this morning and for a few minutes I had hope that they would fix the issue, but no. It took me several tries to get Firefox to open. Even killing the process and trying again didn’t help. The only thing that eventually allowed me to start FF was starting it in Safe Mode (after being prompted). After that FF worked normally even when not in Safe Mode.

Yep, still the same problem for me, although I tried all the workarounds suggested above. And this is definitely not a KDE issue (I’m running GNOME).

I was hoping that yesterdays Manjaro update should solve the problem.
There were both an Firefox update, as well as a kernel update.
It didn’t help, though.

/ Hans Gatu

1 Like

After the new system update and reboot, Firefox did not open its window, and I made different tests :

  • kill the last FF process(es) through task manager,
  • open about:support in a new tab when FF opens and clear start cache,
  • open a “new” window through FF icon on my task bar, then about:support and clear start cache
    but each time that I closed FF and tries to reopen it, no window opens.
    The only thing that worked (for me) was to start FF through Terminal :
firefox --new-window about:support

and click on Clear startup cache… then click on Restart FF
FF reopens the single tab window and my FF window with all my tabs. Then I can close FF and start it without problem.
So, there is problem somewhere … :innocent:

firefox --new-window about:support

That didn’t work for me. That was the first thing I tried before having to attempt to open FF and kill the process a few times until it said something about safe mode. The problem is definitely with FF as this happens on my Ubuntu laptop now as well. I guess we’ll just have to hope they figure out the issue sooner or later.

1 Like

You are right. This workaround seems to work for me, too. Starting Firefox from the Konsole starts 3 processes called Firefox, but no window. Killing one of these 3 processes causes a Firefox window to appear. The Konsole produces the following messages when I kill one of the original 3 processes. I don’t know whether they are useful.

[GFX1-]: glxtest: VA-API test failed: process crashed. Please check your VA-API drivers.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
[2022-12-07T21:48:22Z ERROR glean_core::metrics::ping] Invalid reason code startup for ping background-update

So, there is problem somewhere … :innocent:

There’s clearly a bug, indeed. On another topic, someone mentioned that this could be caused by specific Manjaro settings for Firefox (maybe in the package manjaro-browser-settings). Don’t have any clue, and the process to report this kind of weird and unidentified bug to Manjaro devs is still unclear to me.

This really was just a guess of that “someone”, I guess :wink:
but to rule that one out and for peace of mind
it is easy to deinstall that package.