Skip to content
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

webui: Adding report for JS bugs #5225

Merged
merged 1 commit into from
Oct 18, 2023

Conversation

adamkankovsky
Copy link
Contributor

@adamkankovsky adamkankovsky commented Oct 3, 2023

Modification of the existing bug report system and addition of a report option for critical bugs related to JS.

Based on commit: e242c12

Report looks like this:
image

Bugzilla:
image

@adamkankovsky adamkankovsky force-pushed the webui-js-error-notify branch 2 times, most recently from 14eebfe to 063f4a6 Compare October 3, 2023 11:46
@adamkankovsky adamkankovsky marked this pull request as draft October 3, 2023 11:47
@adamkankovsky adamkankovsky force-pushed the webui-js-error-notify branch 3 times, most recently from 36d1c84 to cfc20ec Compare October 3, 2023 12:06
@adamkankovsky adamkankovsky marked this pull request as ready for review October 3, 2023 12:29
{exceptionNamePrefix + exception.message}
</Text>
</TextContent>
{exception.stack &&
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this was cherry-picked from the commit that I wrote, but as said on slack, I think we do not need to show the stracktrace inside the error modal.
The reason we show the log from journal is to allow the user to edit it so as to remove sensitive information like passwords etc.

So I think it's enough to store the stackstrace into a file, like webui-js-stacktrace.txt, and that we inform the user about the existence of it.

The design can be discussed with @garrett

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll definitely edit it again, I honestly didn't really understand the messages I have to do here, so I at least got the existing solution to work in all cases. Now I get it and I'll edit it

Copy link

@garrett garrett Oct 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @KKoukiou about not showing the stacktrace.

And we wouldn't even show the log, except that it might have some user identifiable parts (although even this is somewhat questionable, as it's on a live system without user data... I suppose a created user or IP address might be shown? I can't think of much else that would be user-identifiable in the logs.)

Ideally, we'd just show a basic summary. People encountering errors can't really do anything about them for the most part.


// Listen on JS errors
window.onerror = (err, url, line, col, errObj) => {
setOops(errObj);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove the console.error, this was used for debugging.

@adamkankovsky
Copy link
Contributor Author

@garrett If it would be possible, I would like to include in this error reporting window instead of the stacktrace block, just a short description of the error and a button to download the stacktrace in txt format, because as @KKoukiou said, there is no need to show the stacktrace unlike the log. This is of course just a sketch, it may turn out differently

@garrett
Copy link

garrett commented Oct 5, 2023

What can someone do with a stack trace, if they're not an Anaconda developer?

(They could report it, but shouldn't that already be handled when they click the button to report it?)

@adamkankovsky
Copy link
Contributor Author

What can someone do with a stack trace, if they're not an Anaconda developer?

They can add the file to the bugzilla for us.

@garrett
Copy link

garrett commented Oct 5, 2023

They can add the file to the bugzilla for us.

There's a send button. Why not send that over?

Why make someone download a file somewhere, then go to the issue, and attach it? Worse yet, they may need to reboot into a working OS or use another computer... and then somehow find the URL for the bug. And this is even assuming that they made an account and signed in with it to report the bug in the first place. This is an extremely high barrier to actually do anything with a backtrace.

It needs to be attached to the report when clicking the button. Anything else is madness, and people will generally not do this (nor even be able to).

@adamkankovsky
Copy link
Contributor Author

adamkankovsky commented Oct 5, 2023

It

This would of course be the ideal situation if pressing the button would automatically pass everything to the bugzilla, since I talked with Radek, the log is added to the bugzilla later using a log file that is taken directly from the device, because the log is in most cases larger than the maximum message size in the bugzilla.
I see a problem here, for example with remote access, where you need to somehow get the log from the device and where it might be better to be able to download the log directly.
As for the js stacktrace, it should fit into the maximum message size.

@rvykydal
Copy link
Contributor

I'd suggest to:

  • handle remote access challenges with attaching log from installer's filesystem separately
  • add just some lightwieight information to "Error detail", like "User interface error: stepIds.error is not a function." (no stacktrace displayed)
  • add the stacktrace to the BZ pre-filled BZ report "Details" (done via URL, it has limit ~ 8kb). Similar to
    newUrl.searchParams.append(
    .

Copy link
Contributor

@rvykydal rvykydal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should keep the backdrop behind the dialog.

@adamkankovsky adamkankovsky force-pushed the webui-js-error-notify branch 2 times, most recently from de9ed41 to 06bb035 Compare October 11, 2023 16:05
Copy link
Contributor

@rvykydal rvykydal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, thank you!
I just see not ideal formatting while trying it in firefox, but that is something I wouldn't block this PR on, I think we can investigate / solve it in a separate PR:
Screenshot from 2023-10-12 10-47-37

Copy link
Contributor

@KKoukiou KKoukiou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please test this with automation tests.

);
newUrl.searchParams.append(
"comment",
"Installer WebUI Critical Error:\n" + context + exception.name + ": " + exception.message
"Installer WebUI Critical Error:\n" + context + name + exception.message + "\n\n StackTrace: " + exception.stack
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For backend errors , the StrackTrace is not going to be there. Maybe remove this from the bug report?

@@ -228,7 +229,6 @@ export const CriticalError = ({ exception, isBootIso, isConnected, reportLinkURL
buttons={[quitButton(isBootIso)]}
isConnected={isConnected}
/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an unrelated change, please make sure to keep your PRs clean from unrelated changes.

@@ -93,7 +93,7 @@ export const BZReportModal = ({
detailsLabel,
detailsContent,
buttons,
isConnected
isConnected,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an unrelated change, please make sure to keep your PRs clean from unrelated changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I dont clean it after my changes.

// Listen on JS errors
window.onerror = (err, url, line, col, errObj) => {
setJsEroor(errObj);
err = null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where do you use the err? Why you set it to null?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is probably not the ideal solution, but the parameters here are necessary for the function to work properly, but lint will display an error if I don't work/maintain the variable in any way, so this seemed like the least painful solution if we don't want to write it out.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah for that the common way to approach is to use underscore instead of the variable name so (_, _, _, _, errObj)

onAddErrorNotification={onAddErrorNotification}
{(criticalError || jsError) &&
<CriticalError
exception={{ ...criticalError, message: jsError?.message || criticalError?.message, stack: jsError?.stack }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

THis is fine as first go probably, but I feel we might need to expect backend and front end crashing in parallel, so we need to report both.

isBootIso={isBootIso}
isConnected={state.network.connected}
reportLinkURL={bzReportURL} />}
{!jsError &&
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I think it's fine to show the page in the background if an error occured. It's blurred anyhow - and the user can't get out of the CriticalError modal without quiting the installer eventually.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, the page must be hidden during a JS error where the error occurs in order to display the modal at all. If the js error is still running it is no longer possible to display any JS code.

@adamkankovsky adamkankovsky force-pushed the webui-js-error-notify branch 2 times, most recently from 64da690 to f35c6ec Compare October 16, 2023 14:44
@adamkankovsky adamkankovsky marked this pull request as draft October 16, 2023 14:45
@adamkankovsky adamkankovsky force-pushed the webui-js-error-notify branch 2 times, most recently from 155da1f to f820f12 Compare October 16, 2023 15:09
Copy link
Contributor

@KKoukiou KKoukiou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a test (always :)) You can test raising an exception from the UI with:

with self.assertRaisesRegex(RuntimeError, "TypeError:.*undefined"):

@@ -177,14 +177,18 @@ export const BZReportModal = ({

const addExceptionDataToReportURL = (url, exception) => {
const newUrl = new URL(url);
const backendMessage = exception.backendMessage ? exception.backendMessage + (exception.jsMessage ? " " : "") : "";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You will probaly need new lines between then backend, jsMessage and stackTrace. Did you try it but I am not sure they are included in the errors (the new lines)

Can you please verify?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked and there are no newlines at the end of the reports. I added them to the url.

@adamkankovsky adamkankovsky force-pushed the webui-js-error-notify branch 2 times, most recently from 9212db0 to 9a853c0 Compare October 17, 2023 14:36
Copy link
Contributor

@KKoukiou KKoukiou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add the screenshot and rebase.

b.wait_visible("#critical-error-bz-report-modal.pf-c-modal-box")
self._testLogReview(b, m, "critical-error")

b.assert_pixels(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was not screenshot generated or added by you. I think it's because the class it wrong.

@adamkankovsky adamkankovsky force-pushed the webui-js-error-notify branch 4 times, most recently from 39ec4ee to 8e3eebd Compare October 17, 2023 15:33
@adamkankovsky adamkankovsky marked this pull request as ready for review October 17, 2023 15:35
ui/webui/test/check-basic Outdated Show resolved Hide resolved
@KKoukiou
Copy link
Contributor

/kickstart-test --waive webui only

@KKoukiou KKoukiou merged commit f8e3b9d into rhinstaller:master Oct 18, 2023
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants