-
Notifications
You must be signed in to change notification settings - Fork 399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wire up client to send errors to http server / Change 'shows details' button to 'report to TripleA' #4687
Conversation
The 'border' method now becomes an overload, bit more obvious that it is a simplified version of 'border(BorderBuilder)'
Enables a swing property in JTextAreaBuilder that will be used in an upcoming change.
User facing change where on the error message pop-up window, instead of having a 'Show Details' button (that would open the console), we now have a 'Report to TripleA' button that opens up a form window. The form window has one text field where a user can enter details (optional), and click 'upload' to then send to http server. Notable code/design changes: - LogRecord maybe having an exception is a bit tricky, there is a lot of logic in formatting the title+body to have data extracted from log record. - Error report window is essentially re-written, focusing on case where we have a LogRecord object and user input is optional. - Error report window model has new design/contract where it interacts with the UI only through interface. The UI has a 'bind' method to let it attach model methods to UI components. This avoids a circular dependency between UI and model, and model and the view interface have no JavaFx or Swing dependencies, so we can swap out different view interfaces between the two without changing model.
Codecov Report
@@ Coverage Diff @@
## master #4687 +/- ##
===========================================
+ Coverage 23.22% 23.3% +0.07%
- Complexity 6213 6221 +8
===========================================
Files 873 870 -3
Lines 70483 70389 -94
Branches 11242 11243 +1
===========================================
+ Hits 16369 16401 +32
+ Misses 52078 51949 -129
- Partials 2036 2039 +3
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well there's not too much I can say about this.
The code looks fine (except for string building of course, that looks always messy)
Also I hesitate a bit to press the button, because this fundamentally changes the way we do debugging (with user problems)
...-core/src/main/java/games/strategy/debug/error/reporting/StackTraceErrorReportFormatter.java
Outdated
Show resolved
Hide resolved
Sincere thank you for looking over the code @RoiEXLab despite any delivery criticisms. It's a bit late to be doing UX design, but I have been considering whether to add 'report' as a 3rd button and keeping the 'show details' button. A subtle benefit here is an error report can now be done with zero key-strokes and two button clicks. A pretty low bar for sending us an error report. To re-iterate, just clicking the 'report' and 'send' buttons will upload the stack-trace. The nail in the 'show details' coffin for me is the unnecessary control, adding UI elements subtracts from the other UI elements. The stack-trace is for dev's, we can see that without a button to 'show details'. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No more objections from my side.
return Arrays.stream(stackTrace) | ||
.map(StackTraceElement::toString) | ||
.toArray(String[]::new); | ||
.collect(Collectors.joining("\n\n")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious where the additional newline comes from.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good eye, fixed: ed10bfa
Dan,
I may be odd as an end user, but I'm always a bit antsy about sending info
out to a third party that I can't examine in detail. I've seen error
reports that gather a remarkable amount of information, some of which might
actually have privacy concerns (such as a list of every other process
running on the machine, for example). I wonder if I'm alone in this.
Obviously, most people won't have the slightest clue about how to evaluate
what they're seeing (in large part, I'm one of them, in fact), so there's
not a lot of practical / actionable benefit from being able to see
details... on the other hand, we're asking users to blindly trust that
we're not gathering anything problematic, and that concerns me as a general
principle, and I wonder if other folks out there might have the same
reaction.
Regards,
Thomas Leavitt
…On Sun, Feb 17, 2019 at 12:12 PM Dan Van Atta ***@***.***> wrote:
Sincere thank you for looking over the code @RoiEXLab
<https://github.com/RoiEXLab> despite any delivery criticisms.
It's a bit late to be doing UX design, but I have been considering whether
to 'report' as a 3rd button and keeping the 'show details' button. That
introduces other problems. Ultimately the stack-trace is visible by any way
a dev would launch the game, and is fundamentally most useful to a dev who
'can' open the console anyways.
A subtle benefit is that the error report can now be down with zero
key-strokes and two button clicks, that is a pretty low bar for sending us
an error report. To re-iterate, just clicking the 'report' and 'send'
buttons will upload the stack-trace.
The nail in the 'show details' coffin for me is the unnecessary control,
adding UI elements subtracts from the other UI elements. We ideally want
most users to click 'report' and upload the error, encouraging that as much
as possible is the objective. We do want to see an increase in any
stack-traces being reported to us.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4687 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEPTgTl5O4bikGvljqETrXDHexlPCuWlks5vObeWgaJpZM4a-voU>
.
--
Thomas Leavitt
Internet enabled since 1990
|
@tvleavitt I originally had in the last iteration a number of confirmations/warnings/previews. For the sake of getting this out the door, it was redesigned to have a much simpler more focused mandate that could land more easily. Adding back in a 'preview' button would not be too difficult, particularly if it is a modal dialog. On the other hand, all info uploaded is viewable from the issue ticket created. I wonder if instead we could just message via tooltip that the error report with all details uploaded will be viewable after upload? So should this be fixed with a preview button, or perhaps better tooltip messaging? |
I created a tracking card to update the preview/messaging treatment: https://github.com/triplea-game/triplea/projects/4#card-17997555; @tvleavitt I'll mention you on the PR update that tries to improve on that point. |
Overview
First two commits are mostly house-keeping/API changes, third commit summarizes the bulk of this update:
Functional Changes
Manual Testing Performed
Before & After Screen Shots
Before
Error message pop-up dialog, note the 'Show Details' button:
After
When there is an error message the 'show details' button is now replaced:
Clicking 'show details' opens this form window that has a hover text. The submit button can be clicked and error report will be sent with the system + log record exception or message data:
If the http server has a problem (simulated by having incorrect github API token), then the client will see this error message and the upload form will remain open:
Happy case where http server uploads, this response will be returned with clickable link:
Example Error Report
triplea-game/test#54
Additional Review Notes
To demo:
log.severe('severe')
or throw an uncaught excpetion inHeadedGameRunner.java
The http server will not be there and it'll cause an error, but it'll be the full flow minus the success message. To get an http server running:
The flow is still pretty interesting even without the http-server running.