Extension process crash handling for persistent background pages (mdn…

…#29480)

* Extension process crash handling for persistent background pages

* Update for feedback

* Feedback update

files/en-us/mozilla/add-ons/webextensions/background_scripts/index.md

@@ -13,6 +13,14 @@ Background scripts or a page are:
 - Persistent – loaded when the extension starts and unloaded when the extension is disabled or uninstalled.
 - Non-persistent (which are also known as event pages) – loaded only when needed to respond to an event and unloaded when they become idle. However, a background page does not unload until all visible views and message ports are closed. Opening a view does not cause the background page to load but does prevent it from closing.
 
+> **Note:** In Firefox, if the extension process crashes:
+>
+> - persistent background scripts running at the time of the crash are reloaded automatically.
+> - non-persistent background scripts (also known as "Event Pages") running at the time of the crash are not reloaded. However, they are restarted automatically when Firefox calls one of their WebExtensions API events listeners.
+> - extension pages loaded in tabs at the time of the crash are not automatically restored. A warning message in each tab informs the user the page has crashed and enables the user to close or restore the tab.
+>   ![Browser window displaying the user message indicating that a page has crashed with the options to close or restart the tab](your-tab-crashed-screenshot.png)
+>   You can test this condition by opening a new tab and navigating to `about:crashextensions`, which silently triggers a crash of the extension process.
+
 In Manifest V2, background scripts or a page can be persistent or non-persistent. Non-persistent background scripts are recommended as they reduce the resource cost of your extension. In Manifest V3, only non-persistent background scripts or a page are supported.
 
 If you have persistent background scripts or a page in Manifest V2 and want to prepare your extension for migration to Manifest V3, [Convert to non-persistent](#convert_to_non-persistent) provides advice on transitioning the scripts or page to the non-persistent model.
@@ -168,8 +176,10 @@ browser.webNavigation.onCompleted.addListener(
 
 ### React to listeners
 
-Listeners exist to trigger functionality once an event has fired. To react to an event, structure the desired reaction inside of the listener event.
+Listeners exist to trigger functionality once an event has fired. To react to an event, structure the desired reaction inside the listener event.
+
 When responding to events in the context of a specific tab or frame, use the `tabId` and `frameId` from the event details instead of relying on the "current tab". Specifying the target ensures your extension does not invoke an extension API on the wrong target when the "current tab" changes while waking the event page.
+
 For example, {{WebExtAPIRef("runtime.onMessage")}} can respond to {{WebExtAPIRef("runtime.sendMessage")}} calls as follows:
 
 ```js
@@ -207,7 +217,7 @@ Data should be persisted periodically to not lose important information if an ex
 browser.storage.local.set({ variable: variableInformation });
 ```
 
-Message ports cannot prevent an event page from shutting down. If an extension uses message passing, the ports are closed when the event page idles. Listening to the {{WebExtAPIRef("runtime.Port")}} `onDisconnect` lets you discover when open ports are closing, however the listener will be under the same time constraints as {{WebExtAPIRef("runtime.onSuspend")}}.
+Message ports cannot prevent an event page from shutting down. If an extension uses message passing, the ports are closed when the event page idles. Listening to the {{WebExtAPIRef("runtime.Port")}} `onDisconnect` lets you discover when open ports are closing, however the listener is under the same time constraints as {{WebExtAPIRef("runtime.onSuspend")}}.
 
 ```js
 browser.runtime.onConnect.addListener((port) => {