Ensure we handle remote frameworker process crashes

RESOLVED FIXED in Firefox 27

Status

()

Firefox
SocialAPI
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: markh, Assigned: markh)

Tracking

Trunk
Firefox 27
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

4 years ago
Bug 891218 introduced the possibility of using a remote process for frameworkers.  If we enable this by default (bug 906839), we need to ensure that we handle a remote process crash in a sane way - at a minimum, ensure the provider gets an appropriate errorState, and ensure that attempts to reload it do the right thing.

FTR, bug 910563 shows an observer that might be useful for this.
Blocks: 859886
(Assignee)

Comment 2

4 years ago
Created attachment 821375 [details] [diff] [review]
0001-Bug-910566-handle-remote-frameworker-process-crashes.patch

This bug builds on Florian's WIP and adds the ability for aboutSocialError.xhtml to reload all crashed workers and tests.

aboutSocialError will, when reloading a provider, also restart any other providers who are enabled and have an error state of "frameworker-error" - it may be that the other providers are in that error state for some reason other than a process crash, but attempting to reload them doesn't really hurt in this case.

The test is loosely based on browser_thumbnails_background_crash.js - it loads 2 providers, crashes the child process, hits the "retry" button in the sidebar's error page, then checks both workers can be pinged.  The code duplication is unfortunate - bug 915518 exists to help unify these later.

I think this patch is worthwhile, but doesn't fully solve the issue - if a worker crashes while no social UI is exposed (eg, the sidebar is closed and the user doesn't click on a notification icon etc) then the user isn't going to be aware of the crash and thus can't take any action to reload the provider.  This could be quite problematic for, eg, Talkilla - users will not be aware of any problem but will not receive calls. However, solving this generally is as much a UX issue as an engineering one - I suggest we open a followup bug for this.

Asking Felipe for review given Shane is on vacation - but also flagging Shane just incase he happens to be reading email instead of sitting on an Italian beach :)  We'd really like to get this landed in the next couple of days.

Try at https://tbpl.mozilla.org/?tree=Try&rev=932a5aef9190
Assignee: nobody → mhammond
Attachment #821287 - Attachment is obsolete: true
Attachment #821375 - Flags: review?(mixedpuppy)
Attachment #821375 - Flags: review?(felipc)
Attachment #821375 - Flags: review?(felipc) → review+
(Assignee)

Comment 3

4 years ago
Comment on attachment 821375 [details] [diff] [review]
0001-Bug-910566-handle-remote-frameworker-process-crashes.patch

Florian, thanks for getting this ball rolling!

https://hg.mozilla.org/integration/fx-team/rev/e095e2f442f8
Attachment #821375 - Flags: review?(mixedpuppy)
https://hg.mozilla.org/mozilla-central/rev/e095e2f442f8
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 27
You need to log in before you can comment on or make changes to this bug.