1618904 - Collect Telemetry on how many times a user requests a remote tab and a content process fails to attach

Status: NEW

(Firefox :: Tabbed Browser, task, P2)

Description

[Mike Conley (:mconley) (:⚙️)]

See, for example, bug 1618308. I suspect this is a case where a content process fails to attach to the frameloader correctly.

The front-end doesn't really handle this case very well - we assume that a content process will launch and attach correctly.

Unfortunately, we don't have much visibility into how often this problem occurs. We should add Telemetry for it.

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

In addition to cases where IPC tries to report some kind of error (failure to launch, or a channel error later) to the ContentParent/frameloader infrastructure, there are some other cases I thought I should mention:

Bug 1488990 is a semi-related problem at the IPC level: if a content process crashes early in startup, before connecting to the IPC channel, there's no timeout for that and on Windows we won't get an OS error either, so potentially the ContentParent could sit around being broken forever.

Bug 1604218 (and bug 1614886) is a failure mode where the content process deadlocks during startup, because of an interaction between our Linux sandbox and ESET antivirus; the user-visible effect is a mysteriously blank tab.

Comment 2

[Chris Peterson [:cpeterson]]

The frontend code needs to handle tab process launch failures regardless of how often processes fail to launch. Is this telemetry probe really needed?

Bug 1618936 has more discussion about how the frontend should handle process launch failures.

This bug is not Fission-specific. e10s content processes can fail to launch, too.