Closed Bug 1630444 Opened 5 years ago Closed 4 years ago

Expand the Launcher Process Failure ping to record failures of starting a sandbox process

Categories

(Firefox :: Launcher Process, task, P3)

Unspecified
Windows
task

Tracking

()

RESOLVED FIXED
82 Branch
Tracking Status
firefox82 --- fixed

People

(Reporter: toshi, Assigned: toshi)

References

Details

Attachments

(5 files)

We use InitializeDllBlocklistOOPInternal for the launcher process to populate the browser process, and for the browser process to populate the sandbox processes.

It's possible that the launcher process completes its task but the browser process fails to start a sandbox process if a third-party application targets only the browser process. In such a case, a user will see Firefox is opened with a blank page without any functionality because no content process is running. We've mitigated this problem by bug 1614885 and bug 1629361.

It would be helpful to expand the launcher process failure ping to collect not only in the launcher process but also in the browser process so that we can learn how often this asymmetric injection happens and who triggers it.

Summary: Expand the Launcher Process Failure ping to record failures of staring a sandbox process → Expand the Launcher Process Failure ping to record failures of starting a sandbox process
Severity: -- → S3
Attachment #9163646 - Flags: data-review?(chutten)

In xul.dll, we used to use WindowsError as an error type of Result.
With this patch, we always use LauncherError which holds additional
error information i.e. a filename and a line number.

This patch adds winlauncher's HandleLauncherError to DllServices
along with InitializeDllBlocklistOOPInternal so that SandboxBroker
can call HandleLauncherError.

Depends on D83638

This patch adds a new property process_type to the launcher process failure
ping, indicating which process type the browser process failed to initialize
as a sandboxed process.

Depends on D83639

Comment on attachment 9163646 [details] data-review-request-for-bug1630444.txt DATA COLLECTION REVIEW RESPONSE: Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate? Yes. Is there a control mechanism that allows the user to turn the data collection on and off? Yes. This collection can be controlled through Firefox's Preferences. If the request is for permanent data collection, is there someone who will monitor the data over time? Yes, Toshihito Kikuchi is responsible. Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under? Category 1, Technical. Is the data collection request for default-on or default-off? Default on for all channels. Does the instrumentation include the addition of any new identifiers? No. Is the data collection covered by the existing Firefox privacy notice? Yes. Does there need to be a check-in in the future to determine whether to renew the data? No. This collection is permanent. --- Result: datareview+
Attachment #9163646 - Flags: data-review?(chutten) → data-review+
Attachment #9163765 - Attachment description: Bug 1630444: Part1 - Always use LauncherError. r=aklotz → Bug 1630444: Part1 - Put LauncherError behind MOZ_USE_LAUNCHER_ERROR. r=aklotz
Pushed by cbrindusan@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/7a5a57611e9c Part1 - Put LauncherError behind MOZ_USE_LAUNCHER_ERROR. r=aklotz https://hg.mozilla.org/integration/autoland/rev/1fd05ba97bd4 Part2 - Add HandleLauncherError to DllServices. r=aklotz https://hg.mozilla.org/integration/autoland/rev/b2ead6bc3fac Part3 - Send the launcher process failure ping from the browser process. r=aklotz
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: