On Tue, 22 Nov 2022 09:47:47 +1100
Stephen Morris <samorris(a)netspace.net.au> wrote:
> I *have* been having a weird issue with nightly for a few
weeks,
> where it doesn't start, but hangs when I start it. I have found a
> workaround, but not a cause. I just invoke chromium, and as soon
> as it appears, I close it. Then the above command to start nightly
> works again. I assume there is some library that isn't being loaded
> properly, and the initiation of chromium loads it, and then nightly
> works too. I am using LXDE, which the package maintainer says is no
> longer being maintained properly, so that could be the issue. I've
> noticed that the menus have a different appearance recently, so some
> system library change could be responsible.
I'm running Firefox nightly on KDE and I don't see this issue, and
under linux I don't see the issue that I see in Firefox Nightly under
windows, which is when there is an update to put on the startup of
Firefox Nightly displays a white screen which gets closed, presumably
because it has found there is an unapplied update, and then displays
its normal interface.
With the start issue you have, do you have the Gnome shell plugin
installed that provides direct install functionality from
Gnome-looks.org, etc? From what I can see the components that plugin
requires are tied to Google Chrome, and it worked fine in Chrome but
I had issues with it in Firefox Nightly getting it to recognise that
those components were actually installed from the repositories, and
from what I've seen that process seems to have changed recently in
that the component in the repositories seem to have been superseded.
I seem to remember seeing an update saying that a package being
installed was replacing the original package.
I haven't noticed any changes to the menus in Firefox Nightly, but
then I haven't really taken a lot of notice of those as I haven't
turned on the option to permanently display them.
I'm not running Gnome (LXDE), but this makes a lot of sense. It might
be that chromium recognizes those components and loads them, and then
when nightly runs it sees them too, and then uses them.
>
> Another possibility is that mesa recently removed support for vaapi
> because of patent issues, and that you need the rpmfusion freeworld
> version to re-enable it. If you have rpmfusion enabled,
> dnf swap mesa-va-drivers mesa-va-drivers-freeworld
I have rpmfusion enabled so I'll have a look at these and also look
at the multimedia link that Greg has provided to see it that sheds
any light on the issue. One issue might be that I used to have
codec's installed that provided the necessary functionality but those
codec are no longer installed, possibly because of re-installing F36
from scratch when I did my hardware upgrade and moved away from raid
so that I could run Linux natively instead of in a VM.
If it isn't confidential, you could provide a link, and I could check
whether it works here. Another data point.