Add user-friendly option to view technical details for unclear errors (e.g., connection failures)

[EchoEllet]

There are many expected errors, such as connection failures, but usually, the app does not try to identify the exact reason due to several reasons:

• The error is platform-specific and different from one platform to another.
• We can't predict every possible error that could happen or identify the exact reason or cause; almost no app does that.
• Technical details are usually not user-friendly, and most users don't care.
• Add more localization maintenance and effort; it becomes harder to localize every possible message, with very little value in return.

We prefer: Connection failed. Please check your internet connection and try again.
over: Connection failed: {errorDetails}

Not all errors require a reason or cause; some errors are straightforward, such as "Too many requests" or "Invalid credentials." This issue does not track these kinds of errors; instead, it is more like connection failures.

The main reason why we want to make it easier for the user to identify the error is so that reporting issues is more convenient and less time-consuming; this way, the user just needs to copy the error details with a button press.

Tip

Logging is not user-friendly; the user needs to either run the app in CLI, or we should provide a debugging window that is disabled by default, and records the exact errors, another layer of complexity with little value. Also, currently Multi-window feature is not supported yet.

Implementation Plan

• Show "Copy error details" or "Show error details" (window/dialog instead of copying). We will provide the "Show error details" dialog with another option inside that dialog to copy the error details.
• This button is shown only for errors that need more context, such as connection failures, but not clear errors (e.g, invalid credentials).
• The button should always be available. An alternative approach is that:
  • We disable it by default, and users need to enable it in the settings. This would make error reporting harder, as now users don't know this option exists, so they report the issue, and we ask them to enable it in the settings, and then try to reproduce the issue again, so the button shows. Inconvenient and a lot of complexity for a simple issue. We could provide the option to hide it.
• When the user presses "Show Details" and the dialog is displayed, it will show the message of the given failure. This message is hardcoded in English and typically contains the technical details.
• When an expected failure includes a suggested action to resolve it — for example, if the user tries to log in to Minecraft with Microsoft but does not have an Xbox account, and the app provides a "Create account" action that opens the link to create one — we should not show the "Show Details" button. The technical details are not useful in this case and would only clutter the UI.
• To reduce maintenance costs, the "Show Details" button will be shown by default for every expected failure that does not have a suggested action, even if the failure is already clear, such as "Too many requests."

[EchoEllet]

The following shows a common anti-pattern that should be refactored:

"authCodeServerStartFailureUnknown": "Unable to start the local server required for login due to an unexpected error: {message}",
    "@authCodeServerStartFailureUnknown": {
        "description": "Shown when the local HTTP server, used to receive Microsoft's redirect after sign-in, fails to start due to an unknown or unclassified error.",
        "placeholders": {
            "message": {
                "type": "String",
                "example": "SocketException: Failed to bind to port",
                "description": "The raw error message returned by the system or runtime."
            }
        }
    },

Should be refactored and fixed to provide this option, rather than inlining the error with the message.

It's not friendly for RTL or non-English languages, and even in English, it's technical and still not user-friendly (long and verbose). This is commonly used across the entire app I will address this as I address #16.