Abrowser 72.0.1 won't load after update.

5 replies [Last post]
grimlok
Offline
Joined: 04/16/2013

I did the system update, which included Abrowser 72.0.1, and now Abrowser doesn't load.

When running from a command line it says:

<_io.TextIOWrapper name='' mode='w' encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe

Any help would be great. I really need my browser.

I made a bug report as well under the issue tracker.

Thanks,
grimlok

cuculus
Offline
Joined: 11/29/2017

I am also having this same problem.

liberpoolesque
Offline
Joined: 01/07/2020

I've just used Abrowser 72 on a fresh Trisquel 8 install and an old one, on different machines, but it worked both times.
Did you try to delete Abrowser's config and cache files, to check if some old plugin or setting is the problem?
Alternatively, does Midori (the default browser on Trisquel Mini) work for you? (After installing, if necessary)

chaosmonk

I am a member!

I am a translator!

Offline
Joined: 07/07/2017

I just upgraded and experienced the same issue. Since liberpoolesque reported that Abrowser 72 works with a fresh install of Trisquel, I suspected that there has been some non-backward-incompatible change in Firefox making older profiles invalid. I ran

$ mv .mozilla/abrowser .mozilla/abrowser~

so that Abrowser would not be able to find my profile, after which Abrowser started normally, creating a new default .mozilla/abrowser.

Unfortunately this loses all user bookmarks, history, settings, etc. It should be possible to copy any important data from .mozilla/abrowser~ to .mozilla/abrowser, but it would be preferable to know exactly what about the older profiles is cause the issue so that we can just fix that. I'll look into this more later today.

cuculus
Offline
Joined: 11/29/2017

Thanks for this quick fix. It worked for me as well.

chaosmonk

I am a member!

I am a translator!

Offline
Joined: 07/07/2017

I found that it was the "network.captive-portal-service.enabled" setting
that cause the segfault for me. Editing ~/.mozilla/abrowser/user.js (if
you don't have user.js, edit prefs.js instead) and changing this setting
from 'true' to 'false' fixed the issue for me.

quidam was unable to replicate this issue by setting that value to
'true', so it seems that it is not this setting alone that causes the
problem, but rather a combination of this setting and at least one
other. However, until we uncover the real problem, setting
network.captive-portal-service.enabled to 'false' may be the best
temporary workaround for users experiencing this issue.