qutebrowser crash reports

[Florian Bruhin]

* Riku Ahonen <rikuah1n at gmail.com> [2015-01-21 10:34:53 +0200]:
> 
> 21.01.2015, 07:46, Florian Bruhin wrote:
> >Hi,
> >
> >(Cc-ing this to the list because I'd like some discussion and ideas
> >about this. For people who have already spoken out about the confusing
> >crash dialog issue - I hear you, I just want to hear more opinions
> >an am unsure about what's best)
> I think your ideas on bug tracker look good. I have some thoughts which
> might be useful:
> 
> "Auto-reject crashes if the stack points to qt_mainloop and Qt version is <
> Qt 5.4"
>
> - I don't know if would be implemented in report dialog or in the paste
> part, but informing the user about this in the crash dialog would help them.
> Something like "you seem to have Qt version x.x which is know to cause
> crashes. Updating to latest Qt might fix this problem."

Since "crash is in mainloop AND Qt is out-of-date" is a really good
indicator for an useless crash report, I plan to not display the crash
report dialog at all.

More something like "qutebrowser was restarted after a fatal crash
caused by the Qt library. Your distribution is using an outdated
version of Qt. Unfortunately, the only way to fix it is to wait until
they have updated." or so, without the ability to report.

> Another thing would be to write a document which describes most common types
> of crashes and what a user can do about them. Maybe something like you wrote
> in the cc'd email. And link to this document in crash dialog.

Hm, I like that idea. I wonder how many people will read that though,
given the big count of reports with *no info at all* at the moment.

I guess a surprising crash just isn't the right time for reading a
document about how to report crashes. :-/

But it'd probably be useful in general to link people to - I opened a
separate issue:

https://github.com/The-Compiler/qutebrowser/issues/480

> When I first sent a crash report with my email address I was a bit surprised
> it ended up on public web page. I think it would be nice to keep contact
> information private or tell the user about this in the crash dialog.

Huh, I think the crash dialog mentioned the reports being public.
Maybe I'm wrong, or this got lost in the first redesign I did.

There are basically two reasons they are public:

- I already had the pastebin set up, and didn't think there would be
  so many reports at the time I set it up, so I just used that.

- Sometimes I just dump the URL into an issue without much more
  information. If someone wants to help fixing the bug, it'd make
  sense for them to be able to see the report. Or in general, it'd be
  confusing if reports linked in public issues needed an account :-/

But yeah - given the amount of "real" issues is going down (and
hopefully will stay down when more tests are running), maybe I should
spend more time opening issues with any *relevant* information from
the full report, and making it private.

I also opened an issue:

https://github.com/The-Compiler/qutebrowser/issues/481

I probably have to set up a separate pastebin for qutebrowser reports.
I guess that'd make sense anyways.

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/qutebrowser/attachments/20150121/211bbb6e/attachment.sig>