1355239 - We should attempt to recover from an extension process crash.

Status: RESOLVED FIXED

(WebExtensions :: General, enhancement, P3)

Description

[krupa raj [:krupa--use this to needinfo]]

In https://bugzilla.mozilla.org/show_bug.cgi?id=1353959#c1, we talked about how we currently don't attempt to recover from an extension process crash.

This is probably something we should do.

Comment 1

[Andy McKay]

Bumping up to a P1, I think we need to talk about what would happen in a crash the side effects and when it would restart.

Comment 2

[Andy McKay]

Kris said that we should restart the background page if it crashes. There were concerns about getting into a continual loop on that though, so I'm not sure what options exist for that.

Comment 3

[Tomislav Jovanovic :zombie]

I think the we might be better off disabling/enabling all web extensions upon process crash, so that web extensions don't get into an inconsistent state if they have something akin to a state machine shared between background page and content scripts.

Comment 4

[Rob Wu [:robwu]]

(In reply to Tomislav Jovanovic :zombie from comment #3)
> I think the we might be better off disabling/enabling all web extensions
> upon process crash, so that web extensions don't get into an inconsistent
> state if they have something akin to a state machine shared between
> background page and content scripts.

A crash induced by one extension should not affect other extensions if possible.
If you meant to say that crashing one extension causes the extension to be disabled, then yes, that makes sense.

FWIW, when an extension process crashes in Chrome, it is disabled and a desktop notification is shown (which can easily be missed if you don't pay attention). The extension is started again when the user clicks on the notification.

What do we want to do here? I'm thinking of trying to restart (up to, say, 2 times (can be controlled through pref)) and otherwise require user interaction to restart (need UI).

Comment 5

[Andy McKay]

A UI needs to be shown for telling the user and also giving the option to submit a crash report. It probably makes sense to seperate that into another bug though.

Comment 6

[Tomislav Jovanovic :zombie]

(In reply to Rob Wu [:robwu] from comment #4)
> A crash induced by one extension should not affect other extensions if
> possible.
All our extensions will run in the same process, so one extension crashing will crash all (active) extensions.


> If you meant to say that crashing one extension causes the extension to be
> disabled, then yes, that makes sense.
With the above in mind, i'm saying we should disable and enable all extensions after the extension process crash.

Comment 7

[krupa raj [:krupa--use this to needinfo]]

reverting this to p1 for 57 (not blocking 56)

Comment 8

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

This is a P1 bug without an assignee. 

P1 are bugs which are being worked on for the current release cycle/iteration/sprint. 

If the bug is not assigned by Monday, 28 August, the bug's priority will be reset to '--'.

Comment 10

[Trevor Skywalker]

This bug was marked as priority 1 two years ago and there has been no work done on it since.

Comment 12

[diamondavocado22]

Attachment: Screenshot of extension crash

Comment 13

[diamondavocado22]

I've been encountering [what I think is] this bug for about a year now.

Occasionally and without any kind of notification or warning, my extensions will simply stop working. Usually I notice this because uBlock and uMatrix stop working and therefore my web browsing becomes littered with ads.

Pop-up menus such as those used in uBlock and uMatrix will simply appear blank, as you can see in my bug report I filed on their Github issues page: https://github.com/uBlockOrigin/uMatrix-issues/issues/231

For me, this bug should be considered absolutely critical, perhaps even classed as a critical security vulnerability.

People like myself rely on extensions to provide security and privacy. Extensions are as much a part of the browser as anything else these days.

To have extensions suddenly stop working without informing the user is a really serious problem because the user might continue working under the assumption that they are secure or their data is being kept private, when in fact their data is being leaked or their browser is being compromised in a way they had previously thought was impossible due to having installed certain extensions.

In my humble opinion there NEEDS to be a notification shown to the user when this happens, and ideally all browser traffic would be cut off immediately so that requests/data which would normally be blocked by an extension could not "leak" out of the browser.

Is there anything that security-conscious users can do right now to mitigate the risks associated with a crash like this?

Comment 14

[Shane Caraveo (:mixedpuppy)]

I'll look to see if we have any crash reporting to indicate frequency of problem.

Comment 15

[[ex-Mozilla] Agi Sferro | :agi]

The OS kills processes aggressively on Android (without necessarily killing the main process), especially when the app is not on the foreground, so this is a must for us to enable remote extensions. My extensions pretty much stop working daily right now on a high end phone (S10).

Comment 18

[Chris Peterson [:cpeterson]]

Tracking this bug for Android Fission milestone M2 (pass tests with Fission enabled).

Comment 19

[Rob Wu [:robwu]]

I filed bug 1678739 to help with exposing the remote type to help with identifying extension process crashes in crash reports.

Comment 20

[Afzal Najam]

IMHO, this should be a P1 as there could be privacy concerns with some extensions not being able to come back up, leaking data all over until the user realizes that the extension is not working.

Comment 21

[Chris Peterson [:cpeterson]]

Extension process doesn't need to block Android Fission.

Comment 23

[cheater]

this is a 5 year old report, and it clearly has severe security and privacy implications, please revise the type (it's a bug, not an enhancement request) and severity and priority.

Comment 24

[William Durand [:willdurand]]

Looks like this has been fixed.

Comment 25

[krupa raj [:krupa--use this to needinfo]]

aww, it is the end of era. I filed this bug 7 years ago