In defence of AI, that was my mistake and not the AI. But I suspect you have your mind made up in regards to this topic.
KDE Plasma “6.1” ??
Um, the OP is on Leap 15.6, which uses KDE Plasma “5” by default … and it was confirmed by the “inxi” output in a previous Reply.
Yes … I see now:
Desktop: KDE Plasma v: 5.27.11 tk: Qt v: 5.15.12 wm: kwin_x11 vt: 2
dm: SDDM Distro: openSUSE Leap 15.6
I’m bad. I missed that.
Still, I think the user should try deleting .mozilla (after backing up their bookmarks).
If I wanted to ask AI I would have asked AI. On this forum I am interested in the real experience of the real humans, not in copy-pasted AI result. If you do not have anything own to say, do not answer. That is that simple.
The point was it was not an AI answer.
Yeah a bit drastic, but why not.
Bookmarks and profile preferences not a problem. I use Floccus for bookmarks and essentially the same profile is cloned in a number of other computers anyway.
That is what I’d call a “last ditch attempt” at finding the issue.
Why? Because it’s where Mozilla apps store user-specific configs, i.e., personal settings that are separate from the Moz core files.
I would never delete it … as the last ditch effort, I’d rename it, to something like “.mozilla–saved”. That way, a quick test can be done, and if nothing changes, you can rename it back to “.mozilla”.
One also has to consider that the “.mozilla” sub-dir tree stores NOT just information about Firefox, but Thunderbird, and so on.
.
EDIT: … also, consider the OP has installed the Flatpak version, so installing that is as if Firefox never existed before … and for some odd reason, the issue persists.
Somewhat off-topic aside
To be fair, I don't see a problem with AI-assisted answers, on the contrary. It's not like @oldcpu is a bot or did a straight copy pasta (though even that could be useful, e.g., if the poster used a prompt that wouldn't have occurred to me).Thunderbird stores its emails under .thunderbird. not in .mozilla.
Anything else is easily setup . Takes FAR LESS time than multiple crashes.
Sure rename .mozilla to .mozilla-saved but don’t overstate the utility of .mozilla. Deleting it is not the end of the world (and far less painful than crash after crash after crash), albeit I won’t deny changing its name is a better idea.
Bookmarks are the main item to keep (and frankly, IMHO, one should regularly backup their bookmarks).
On my computers, Thunderbird uses ~/.thunderbird. Nothing else but Firefox seems to live under ~/.mozilla. Obviously, the renaming suggestion is always appropriate (many of us do that but call it “delete” anyway)
One thing that is intriguing is that it was mentioned that FF version " 141.0.2" is being used.
But the default openSUSE version (at least on my machine) is " 140.1.0esr" (Extended Support … in the default repos).
Then I thought I’d check the “zypper lr -d” output again. And below is a snippet of that output. But there is a FF in the default-level repos.
The only reason a person would want to ADD (at least to me) that “mozila obs” repo is to get a newer version than what is in the standard repo.
But it’s interesting that now, that repo is NOT Enabled.
(??) So, did the OP Enable that repo (mozilla obs), installed the newer version, then at some point, Disable that repo. So, now, maybe zypper is commingling (improper) packages from the default repos (?). So, code in the FF 141.0 version is calling upon supporting libraries that are not at the proper level (?).
Or … maybe not (scratches top of head).
# | Alias | Name | Enabled | GPG Check | Refresh | Keep | Priority | Type | URI Service
---+--------------------------------------+-----------------------------------------------------------------------+---------+-----------+---------+--------------------------------------------------------
9 | mozilla | Mozilla based projects (openSUSE_Leap_15.6 | No | ---- | ---- | - | 99 | rpm-md | https://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.6/ |
10
So, how did you execute -strace-??
It’s important to provide the proper argument(s), such as if a fork happens, we’d want to capture what’s happening in the forked process. And so on …
What exactly was upgraded?
You could check to see what was updated with something like the following (albeit if your update is massive then 20 may not be enough):
rpm -qa --last | head -20
A lot:
zypper refresh && zypper update
But that was well after I started having the problem. The thread also details some other going ups and downs on Mesa and Firefox versions (hence why @myswtest finds the Firefox version numbers / repo statuses confusing).
I think I’m reasonably confident that it’s something in my home directory or otherwise part of my Linux user profile (not Firefox’s) that’s screwing things up. Today I’ve been running all day with su -l tempuser + firefox so I’ve got a copy of the same binary that crashes when ran as me, running in my X server with no issues, whereas mine keeps crashing regardless of which Firefox profile I use, safe mode, hardware acceleration, etc.
Well, it was worth a try.
- Firefox closed
- Network offline (because one less factor to deal with)
mv ~/.mozilla ~/.mozilla-NOMORE- Firefox started
- I’m going through the settings, activating permanent private mode, etc.
- It crashes
So, nothing under ~/.mozilla that was causing the crash.
So, how did you execute -strace-??
Good point. I did not think about forks.
I’m running it again now with strace -f -o firefox_strace.log firefox let’s wee what happens.
I run -strace- in a number of different ways. It just depends on the situation. Most recently, I ran it as shown below … testing for another issue in a post.
To do a quick summary for an “strace debug” ,
I use “-D -f -t”, as shown below.
For me … that usage provides revealing information.
… And it may be necessary to re-run with more args ![]()
The below was executed, checking for a Dolphin (file manager) issue.
user@mach :~> history | grep strace
...
2697 strace -o dol.txt -D -f -t dolphin
...
I’m basically hoping to check open() and similar calls near the crash point see if that gives a clue of what might be going on.
So far what’s going on is that it refuses to crash when watched closely. ![]()
But it’s interesting that now, that repo is NOT Enabled.
@licehunter … why is the “mozilla obs” repo now Disabled??
@licehunter … why is the “mozilla obs” repo now Disabled??
Because I don’t need it. It was added some time ago when something I was testing required a Firefox version more recent than available on Leap at the time. Then it stayed enabled until I got around to disabling it now (I could have just removed it altogether).