E10S content-process crashes shouldn't trigger startup crash detection

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
6 years ago
4 years ago

People

(Reporter: smaug, Unassigned)

Tracking

unspecified
x86_64
Linux
Points:
---

Firefox Tracking Flags

(e10s+)

Details

(Reporter)

Description

6 years ago
The safe mode dialog kicks in too easily. For example when doing some
e10s related things, killing browser once makes the dialog to popup next time.
Perhaps value 4 would be more reasonable.
(Reporter)

Updated

6 years ago
Blocks: 294260
What exactly does "doing some e10s related things" mean?
(In reply to Olli Pettay [:smaug] from comment #0)
> The safe mode dialog kicks in too easily. For example when doing some
> e10s related things, killing browser once makes the dialog to popup next
> time.

Why don't we just fix this case so that it follows the number in the pref? Increasing the number doesn't actually fix the problem.
(Reporter)

Comment 3

6 years ago
(In reply to Justin Dolske [:Dolske] from comment #1)
> What exactly does "doing some e10s related things" mean?
Run E10s enabled Firefox (so that tabs are running in a separate process).
Or use the test.xul: firefox -chrome chrome://global/content/test-ipc.xul
So it's content-process crashes that are causing this? We should just disable incrementing the crash-counter thing there.
(Reporter)

Comment 5

6 years ago
(In reply to Justin Dolske [:Dolske] from comment #4)
> So it's content-process crashes that are causing this?
I don't know. I don't know how we detect crashes.
Adjusting summary to match goal; I don't think we actually want to change the pref, just make content-process crashes not count towards startup crashed.
Summary: Increase toolkit.startup.max_resumed_crashes value → E10S content-process crashes shouldn't trigger startup crash detection
tracking-e10s: --- → +
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.