decide where to add the rewards debugging info (follow up from #1174)

[kjozwiak]

As a follow up from #1174 (comment), we'll need to decide where to add the debugging information that #1174 is implementing and how it's accessed. As per @bridiver via #1174 (comment), adding a link to the above information under chrome://version will require a lot of unnecessary work/patching. The new location should also be easy enough that users should be able to find it without much difficulty.

This work should land in the same milestone as #1174.

CCing @rebron @bbondy @davidtemkin @bridiver @LaurenWags @NejcZdovc @emerick @bsclifton

[NejcZdovc]

My suggestion would be to add it into settings page where we will have new rewards section

[davidtemkin]

@NejcZdovc I think we're adding confusion by creating settings section for Rewards while Rewards has its own settings page. For clear browsing data that arrangement is supportable, but I think this element, and others, should be somewhere inside Rewards. We should probably discuss as a whole cc: @jenn-rhim @mandar-brave

[mandar-brave]

@davidtemkin @NejcZdovc we had designed a complete diagnostics system spec for something similar; never shipped due to priorities. Wondering if easier to switch to those designs.

For the diagnostics spec (Which had a windows for debug log), the plan was to install the same on About Brave.

[LaurenWags]

Personally I don't have strong feelings about where the link to this page should be, somewhere on brave://rewards feels natural - not sure if under the wallet panel is too obvious:

Elsewhere is fine, however, I do not think this link should be available from the backup/restore modal. Reason being is that if there is a server issue or something else that triggers the below error, the backup/restore screen is inaccessible since you can't click on the gear icon:

[kjozwiak]

Another possibility is add a new section under brave://settings like we did with Sync. Example:

We already have the above implemented, it would be as simple as copying/pasting the code, renaming the header to Rewards or something else and changing the link. This also decouples it from brave://rewards in case that becomes unaccessible for whatever reason.

[NejcZdovc]

@kjozwiak yup agree (#3538 (comment)), will talk more with product about it as I would like to place more stuff in settings page. Currently we don't have settings section in rewards (for general stuff).

[LaurenWags]

That's a really good point @kjozwiak, if brave://rewards becomes inaccessible we do want users to be able to still access this. Agree with you and @NejcZdovc re: placing something in settings.

[kjozwiak]

Have we made a decision on where we're going to place the link in the UI? Looks like this has lost some steam. #1174 as already landed in 0.63.15 Chromium: 73.0.3683.75. We should get this resolved before 0.63.x moves into beta.

[srirambv]

This is really important in terms of getting logs from users. We've seen time and again users going silent when we ask them to try to capture logs but because running via console/terminal isn't everyones strong skill. We should probably implement something like brave://translate-internals/#event-logs in brave://rewards-internals where we can capture logs. My suggestion is we add checkboxes which adds command line flags. Checking the command line flags should prompt the user to relaunch the browser which adds those command line flags for that restart session. Closing the window should reset. Only pass the flags when the user checks it. Also a good item to do add a search box in the internals page when the logs are captured so that its easy for capturing ads logs. We can just add only the required lines in the logs that we actually need for debugging and not dump everything. This will help a lot for @jonathansampson and @Brave-Matt as they talk to a lot users on Reddit and Twitter. Its easy for users to just take a screenshot and share as well so that it makes it that much easy to get logs from users.

This will also be helpful if the same is done for Android

cc: @kjozwiak @atsyed87 @alexwykoff @mandar-brave @davidtemkin @NejcZdovc @tmancey @SergeyZhukovsky @samartnik

[kjozwiak]

Agreed 100% with @srirambv regarding the above. We really need to start looking into ways of making it easier to retrieve logs from users that are having issues with ads and rewards. Once we start getting more users using ads, it will be extremely difficult to support.

With the current process, we basically need to ask users to run Brave via a handful of browser flags via the terminal. This is a huge technical jump for some users and most of the time, the support inquiries stop there. Users want a convenient way of getting debugging information or they won't be willing to help.

CCing @jsecretan who might have some idea's on this as well. I believe @jonathansampson has run into tons of pains trying to support users with ads.

[tmancey]

I have spoken with @alexwykoff and raised my concerns especially with mobile. Ads currently produces most of the debugging information that we would require to diagnose issues from Muon which was displayed within the browser. I agree this should be prioritised and added before Android Ads is released.

[srirambv]

Here's another use case from @agentofuser that requires logs to be shown within browser which makes sense as well https://github.com/agentofuser/curling-generosity#full-private-transparency. As a (power) user I'd like to know whats going by checking logs on my own and to see if services are down.

[srirambv]

Bumping the thread. Needs to be a higher priority than P4 now. This was discussed during the Android triage as well. It would be extremely challenging to get logs for Android as users need to

1. enable developer mode on their device (which am not sure how many would be willing to do)
2. need to install Android Studio (again people wold stop responding when we ask them to install and Android studio is pretty huge) to capture logs.

This should be treated as P1/2 and implemented soon.

cc: @jsecretan @davidtemkin @anthonypkeane @bsclifton

[NejcZdovc]

@srirambv this issue is regarding where to add link. You can always access brave://rewards-internals directly. I think if there are problems with logs on android issue should be opened there

[srirambv]

@NejcZdovc this issue I believe is specifically for adding the debugging info and not just where it needs to have the link. Like you said we already implemented brave://rewards-internals as part of #1174 and can be accessed directly and doesn't need linking anymore. The only remaining problem from #1174 is showing the debug info on the browser itself somewhere.

We don't have any debug info added into brave://rewards-internals, right now just have wallet ID, persona ID and User ID which isn't enough for support. I assume all debug info for both rewards and ads in specific should be made available somewhere in one of the internal pages. Based on #3538 (comment) debug info for both rewards and ads on Mobile is difficult to get based on what I mentioned above.

[srirambv]

+1 from @samc05 via #5202 for showing Ad Rewards Summary Log

[alexwykoff]

Spec is underway and I'll be pulling folks from above into calls to make sure we have this nailed down. There will be implementations for each platform.

[Miyayes]

I think this is resolved with brave://rewards-internals in any recent version of Brave (as of 2021).