Mu should be crash-friendly

[tmontes]

(as suggested by @ntoll here)

Issue

• All software has bugs.
• Silent crashes are the worst, especially in tools like Mu, which strive to be beginner friendly: what's a user to do when their actions -- which they might be unsure about -- lead to a very unfriendly Mu crash that just closes away the GUI window?!...

Idea

• Let's try to improve Mu in such a way that it better catches its own hard-failures.
• In such horrible cases, we could try to bring up a "panic dialog" telling the user that something very unexpected happened, not their fault, and asking/guiding them to log an issue here -- it could even be semi-automated, who knows?

Facts

• We have several reports of Mu crashes currently open: #956, #938, #934, #897, #889, #873, #734, #717, #696, #666, #635, #584. They don't seem to be all due to a common underlying condition, but a few result from unhandled exceptions which Mu should catch somehow.

Thoughts

• Mu should do its best to handle uncaught exceptions.
• There's no way, I fathom, we'd target and handle C-level failures, right? :)
• AFAICT, this will need to be done the Qt way, somehow: wrapping Qt's event loop in a try/except BaseException won't work for all sorts of reasons.
• The kind of Mu behaviour when such fatal failures are detected needs to be defined. What should happen? Which kinds of end user interaction would make sense?
• Implementing such capabilities is bound to be very tricky: some failures might prevent the failure-handling code to run successfully. For example, we don't want that code to destroy diagnostic information, or add "noise" to an already potentially complex failure scenario.

I feel this is a very important and non-trivial issue that we should seriously consider including, for the benefit of both Mu users and contributors: such tooling should lead to a better user experience and to more detailed, hopefully actionable, crash reports that contributors can address directly. :)

Shall we discuss this?

[tjg-global]

Definite +1 for me -- although without any concrete proposal to make at present. (Apart from the obvious try-except approach which you say has complications through the Qt event loop).

Just dropping in here (as part of any wider discussion): https://docs.python.org/3/library/sys.html#sys.excepthook

[dlech]

Could we create a "runner" program that runs Mu as a subprocess and displays a message if the exit code is non-zero? This would catch everything, even segmentation faults.

Example:

import pathlib
import subprocess
import sys

args = [
    sys.executable,
    str(pathlib.Path(__file__.replace('runner.py', 'main.py')).absolute()),
    # TODO: append additional command line args from sys.argv
]

with open('log.txt', 'w') as log:
    ret = subprocess.run(args, stderr=log)
    if ret.returncode:
        # TODO: Use Qt to show this in dialog box along with a button to
        # automatically send log.txt somewhere or view it locally
        print('Something bad happened')
        sys.exit(ret.returncode)

We could still run Mu directly for development/debug, but in production, it could be run with such a wrapper.

[tjg-global]

@dlech The idea is attractive. My initial misgiving would be that any additional mechanism adds a layer of uncertainty / risk which provides yet another source of possible bugs. In other words, we'd have to be absolutely certain that the additional (support / debugging) overhead was outweighed by the benefits.

[tmontes]

My ad-hoc exploration in a different context lead me to this project, which might be useful in this context: qcrash @PyPI and @GitHub...

While not exactly the approach @dlech was mentioning, it may help address the majority of crashes we've observed with, hopefully, very little effort on our part.

Deferring evaluation to a later stage. Just wanted to "write it down" and share.

[tmontes]

I dedicated some time to explore the above mentioned qcrash library. For that, I created a minimal project I called qtcrashme. Here are my findings.

The experience

Running qtcrashme gets us this window:

Clicking the Click to crash button triggers a raise BaseException(...) here. With qcrash it is caught and a default "something bad happend" dialog is displayed:

Clicking the Show Details... button expands the dialog to include the traceback:

Clicking the Report button closes that dialog and brings up a new one, again bundled within qcrash, with a pre-filled Title and an empty Description area for the user to enter text:

As soon as some input is added to the Description, the Submit on github and Send email buttons become active:

Clicking the Send email button triggers the default email client with a ready to send email message. Here's what I got in my case:

Clicking the Submit on github button instead brings up yet another qcrash bundled dialog, allowing the user to review what will be submitted to GitHub, including the issue text...

...and the log, which will be submitted as a linked gist:

Lastly, clicking the OK button, brings up yet another dialog asking for the user's GitHub credentials, such that a new issue can be logged on their behalf:

No feedback is given as the GitHub API interaction progresses. It felt like ~3-5 seconds on my attempts. Once done, a final qcrash dialog is shown:

Clicking the Yes button, takes you to the just logged issue which, interestingly, links to the gist containing the log file contents.

Once this process is complete, the original UI is available and running -- whether it is still of any use after such failure will depend on the code, naturally. :)

What I like

• It works, with very little effort.
• ...but I had to patch it a bit: it was posting GitHub gists without authentication and failing.
• The idea of posting the log as gist linked to the issue: much more readable.

What I don't like

• GitHub submission is not beginner friendly:
  • Too many interaction steps.
  • Very little to no guidance: title? description? what's a beginner to type in?
  • Does a beginner even have a GitHub account?
• Having Mu asking for a user's GitHub credentials: why should they trust Mu with them?
• The GitHub API interaction:
  • No feedback while in progress: users are bound to stare at it and wonder what's going on.
  • It something fails no feedback is given to the user. :(
  • I experienced two different kinds of failures in my brief exploration:
  • Posting a new gist required authentication and was failing (thus I patched qcrash a bit).
  • My Python install trusts no CAs by default. The GitHub HTTPS certificate validation was failing, thus, but no feedback was given to me, as an end user.

What prompts discussion

• Email submission is more beginner friendly, but do we want to handle these reports via email? Maybe not.
• Not sure how easily it could be:
  • Translated to all the Mu supported UI languages.
  • Made to follow Mu's UI theme.

Wrap up

This was interesting. Like I initially wrote, I think the key thing is coming up with a good answer to:

The kind of Mu behaviour when such fatal failures are detected needs to be defined. What should happen? Which kinds of end user interaction would make sense?

From there, everything else becomes a "technical detail". :)

[ZanderBrown]

If the dialog is coming from the same instance as mu itself using our theme should be fairly trivial, otherwise it may require a little more investigation

Overall that UX isn't overly great but hopefully it doesn't get seen often

[dybber]

Ideally, the user would just hit report and then the crash log would be directly submitted to Github as an issue. Here's a Github app that receives emails and creates issues: https://fire.fundersclub.com/ - do you it could be misused for spam, or does Github do effective spam filtering?