Closed Bug 1619955 Opened 4 years ago Closed 3 years ago

content process crash reporting dialog missing email address field

Categories

(Firefox :: General, defect, P3)

Product:
Firefox
Component:
General
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: willkg, Unassigned)

References

Details

The crash report dialog you get when a content process crashes doesn't have an email address field.

We should add one so it's in parity with the main process crash report dialog.

Further, (and maybe this should be a new bug), when opting-in to auto-reporting content crashes, maybe Firefox should use the email address you filled in.

Moving to DOM: Content Processes because the changes here will all be in the front-end rather than the crash reporting code itself.

Component: Crash Reporting → DOM: Content Processes
Product: Toolkit → Core

(In reply to Gabriele Svelto [:gsvelto] from comment #1)

Moving to DOM: Content Processes because the changes here will all be in the front-end rather than the crash reporting code itself.

Moving this bug to Firefox frontend component. The "DOM: Content Processes" component is for Gecko's process launching and IPC code.

STR: load about:crashcontent

Component: DOM: Content Processes → General
Product: Core → Firefox

Seems this was deliberate in bug 1309316. Per the discussion in the bug, UX felt it added noise / barrier to submission, and there was no significant gain from having the information. So I suspect this is wontfix. Mike?

Blocks: 1309316
Flags: needinfo?(mconley)

I have used e-mail addresses from crash reports to contact users in the past. It takes time but sometimes there's no real alternatives when nobody inside Mozilla can repro a crash and the report doesn't have enough information to figure it out.

(In reply to :Gijs (back Thu 12; he/him) from comment #3)

Seems this was deliberate in bug 1309316. Per the discussion in the bug, UX felt it added noise / barrier to submission, and there was no significant gain from having the information. So I suspect this is wontfix. Mike?

Yeah, that looks like where we ended up with the discussion. It looks like we left the field in but hide it. It can be turned back on by setting browser.tabs.crashReporting.requestEmail to true.

If UX is happy to reconsider, then let's do it.

Flags: needinfo?(mconley)

What was the impetus for filing this bug? Is there a project with attached UX/eng resourcing who could work on this? If not, I think this is going to end up in the pile of P3s with no expected date to get this fixed.

Flags: needinfo?(willkg)

So, it seems like there are a couple of things going on here.

  1. As Will mentions in the description, we would like the content process crash dialog to be the same as the main process crash dialog, for consistency.
  2. As BSmedberg mentioned in comment 15 only around 1% of users enter a valid email address, so there's a bunch of cognitive overhead for something that is mostly unused and unusable.

We should get input from UX (represented here by Markus 😉) as to whether they would like to remove the field on the main process dialog, or show it on the content process dialog, and if they choose to show it, what sort of indication they would like to add to indicate that it's optional in both cases.

(Marking as P3 for now. If it gets a design, we can revisit the priority.)

Flags: needinfo?(willkg) → needinfo?(mjaritz)
Priority: -- → P3

Socorro goes out of its way to not not collect data that allows people to correlate crash report data in Socorro with individual users in other Mozilla data sets. For example, we remove the TelemetryClientId and other annotations from crash report data at ingestion.

The problem is that our process for handling crash report deletion requests requires the user filled in the email address field. We can use this to prove the user owns those crash reports and delete them accordingly. That doesn't work if the email address isn't in all the crash report dialogs.

I've talked with Alicia about this. We don't have another way to support user deletion requests for Socorro crash report data. I have another bug open for figuring out a different way, but I don't think that's going to happen any time soon especially since we sort of have the email address field method.

I'd rather we (Mozilla) decided to have email address fields or not. This middling situation makes things complicated.

(In reply to Blake Winton (:bwinton) (:☕️) from comment #7)

So, it seems like there are a couple of things going on here.

  1. As Will mentions in the description, we would like the content process crash dialog to be the same as the main process crash dialog, for consistency.
  2. As BSmedberg mentioned in comment 15 only around 1% of users enter a valid email address, so there's a bunch of cognitive overhead for something that is mostly unused and unusable.

We should get input from UX (represented here by Markus 😉) as to whether they would like to remove the field on the main process dialog, or show it on the content process dialog, and if they choose to show it, what sort of indication they would like to add to indicate that it's optional in both cases.

(Marking as P3 for now. If it gets a design, we can revisit the priority.)

I agree we should keep them consistent.
Having the field does not provide user value and by adding complexity might also impact the amount of submissions negatively.
So if we do not get significant business value out of having that field we should remove it for both cases.
Not having worked with crashes I can not say if the few successes we had with e-mail follow-up are worth the bulk collection and justify collecting this added data. Will can you make that call, or know who would?

Flags: needinfo?(mjaritz) → needinfo?(willkg)

Having the field does not provide user value and by adding complexity might also impact the amount of submissions negatively.

I've never seen any evidence or research or other analysis that concludes that having the email address field negatively impacts submissions. I get how it's generally true, but do we have anything about this specific situation?

Not having worked with crashes I can not say if the few successes we had with e-mail follow-up are worth the bulk collection and justify collecting this added data. Will can you make that call, or know who would?

I'll talk with Alicia and with people who have made the claim that the email address helps them and follow up here.

(In reply to Will Kahn-Greene [:willkg] ET needinfo? me from comment #10)

Having the field does not provide user value and by adding complexity might also impact the amount of submissions negatively.
I've never seen any evidence or research or other analysis that concludes that having the email address field negatively impacts submissions. I get how it's generally true, but do we have anything about this specific situation?
No, we have not confirmed this for this specific case.
But we have both cases now. So if you are curious you might be able to measure the difference in submission rate.

No, we have not confirmed this for this specific case.
But we have both cases now. So if you are curious you might be able to measure the difference in submission rate.

I don't think I can prove your claim one way or the other with our existing data since the two crash reporting dialogs occur in very different scenarios.

Depends on: 1626277

Collecting email addresses for content process crash reports is "nice to have", but a very low priority for the Fission team. If the UX team wants to redesign the crash reporter to collect email addresses, that's fine. Otherwise, there is no need to commit to any work on behalf of the Fission team.

However, with Fission's new process architecture adds some new wrinkles for the crash reporter UI. An iframe process can crash without crashing the entire page or tab. I reached out to the UX team to discuss crash reporting for crashed iframes.

Hey willkg, you wrote:

I'll talk with Alicia and with people who have made the claim that the email address helps them and follow up here.

Did that talk ever occur? It seems like someone just needs to make a call here one way or another, and we can flip the pref or WONTFIX this.

It did. I talked with Alicia about this. I also talked with the Fission team about this since it affects them the most since Fission crashes are content crashes.

The consensus was to let this situation site like this for a few months and if nothing has occurred to advance this further, switch gears to remove the Email field from all crash reporter dialogs and from Socorro and WONTFIX this.

Flags: needinfo?(willkg)

(In reply to Will Kahn-Greene [:willkg] ET needinfo? me from comment #15)

It did. I talked with Alicia about this. I also talked with the Fission team about this since it affects them the most since Fission crashes are content crashes.

The consensus was to let this situation site like this for a few months and if nothing has occurred to advance this further, switch gears to remove the Email field from all crash reporter dialogs and from Socorro and WONTFIX this.

Should we be doing this now, as it's been 6 months since comment 15?

Flags: needinfo?(willkg)

Yes! My plan this quarter is to remove the Email field. I'm working on other things at the moment, but will probably get to this in a week or two.

I'll spend some time today to update the related bugs.

Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(willkg)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.