Opened 8 months ago

Last modified 8 months ago

#7031 new defect

Issue reporter should also have a crash reporting choice

Reported by: jidanni Assignee:
Priority: Unknown Milestone:
Module: User-Interface Keywords:
Cc: greiner, kzar Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by greiner)

Background

chrome-extension://cfhdojbkjhnklbpkdaibdccddilifddb/issue-reporter.html
is great.

Except it only has two choices:

Adblock Plus is blocking too much

Select this option if the page lacks important content, displays incorrectly or fails to function properly. You can determine whether Adblock Plus is the cause of the problem by disabling it temporarily.

Adblock Plus doesn't block an advertisement

Select this option if an advertisement is displayed despite Adblock Plus being enabled.

What to change

Add a third choice to the issue type selection in the issue reporter:

The tab crashed / produced an "aw snap" page

It could then gather all relevant info...

See ui#230.

Change History (9)

comment:1 Changed 8 months ago by jidanni

OK, maybe

Adblock Plus is blocking too much
Select this option if the page lacks important content, displays incorrectly or fails to function properly. You can determine whether Adblock Plus is the cause of the problem by disabling it temporarily.

means to include crashes.

But when the page crashes, no user will think "Oh, Adblock Plus is blocking too much / little".
Same when your car crashes. It just crashed. Blame is for the forensic team. Hence a third choice is needed.

comment:2 follow-up: Changed 8 months ago by greiner

  • Cc greiner kzar added
  • Component changed from Unknown to User-Interface

I'm not sure we'd even be able to access any of the data that'd be helpful for analyzing such crashes. @kzar Any ideas?

The least we could do is provide a link to the Help tab in the extension's settings page where we inform users about various ways to report general issues to us.

comment:3 Changed 8 months ago by greiner

  • Description modified (diff)
  • Summary changed from issue-reporter.html should also have a crash reporting choice to Issue reporter should also have a crash reporting choice

Added link to GitLab issue.

comment:4 Changed 8 months ago by jidanni

Anyway, at least to make the user more comfortable, add this "crash" choice,
and maybe even add an "other" catchall choice.

What these choices actually exactly do is an internal issue. At least the user feels he can express himself correctly.

comment:5 in reply to: ↑ 2 ; follow-up: Changed 8 months ago by kzar

Replying to greiner:

I'm not sure we'd even be able to access any of the data that'd be helpful for analyzing such crashes. @kzar Any ideas?

We'd need to have already started recording requests and filter hits for the tab, before it crashed. So, unless the crash could be reproduced reliably I'm not sure how useful that would be. (I know with the recent problem with the Debian Chromium build that crash _could_ be reproduced reliably, but in my experience that's pretty rare.)

The least we could do is provide a link to the Help tab in the extension's settings page where we inform users about various ways to report general issues to us.

Yea, that might be useful. I guess we could make similiar suggestions to the Chrome guys in the recent issue, for example going to chrome://crashes?

On the other hand, perhaps that choice would be confusing for some users? Perhaps we're better leaving browser crashes to the browser developers to support?

comment:6 in reply to: ↑ 5 ; follow-up: Changed 8 months ago by jidanni

Replying to kzar:
(chrome://crashes doesn't work in Linux/Debian sid.)

Crash reporting is disabled.
Crash reporting is not available in Chromium.

comment:7 in reply to: ↑ 6 Changed 8 months ago by greiner

Replying to kzar:

On the other hand, perhaps that choice would be confusing for some users? Perhaps we're better leaving browser crashes to the browser developers to support?

I'll leave that up to Product to decide.

But it also depends on how important and how frequent such crashes are. On the one hand, maybe we shouldn't bother with browser crashes since there's nothing we can do about the underlying issues anyway and can only apply workarounds.
While on the other hand, extension crashes may occur for various reasons and I assume that they can usually be traced back to something the extension does (e.g. background processes being shut down due to memory leak).

Replying to jidanni:

(chrome://crashes doesn't work in Linux/Debian sid.)

You're right. In that case maybe https://www.chromium.org/for-testers/bug-reporting-guidelines/reporting-crash-bug would be a better source to link to because it also provides instructions on how to retrieve the crash ID when crash reporting is disabled.

comment:8 Changed 8 months ago by kzar

I'll leave that up to Product to decide.

Fair enough, but FWIW my vote is to not to add this crash reporting functionality, for four reasons:

  1. There's not much we can do for the user if the browser or browser tab crashes.
  2. The browser should inform/help the user in that situation not an ad blocking extension.
  3. The extra option in the issue reporter might confuse users, or at least make the tool harder to use.
  4. It's pretty rare that tabs crash reliably like this anyway.
Last edited 8 months ago by kzar (previous) (diff)

comment:9 Changed 8 months ago by jidanni

Debian has just updated its
/usr/share/doc/chromium/README.Debian
telling how to get a trace. (Different than Ubuntu.)

OK, then at least change:
Select this option if the page lacks important content, displays incorrectly or fails to function properly or even crashes.

Version 0, edited 8 months ago by jidanni (next)
Note: See TracTickets for help on using tickets.