-
Notifications
You must be signed in to change notification settings - Fork 893
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
Add additional details to webcompat report #20052
Conversation
A Storybook has been deployed to preview UI for the latest push |
b2bab5c
to
459c8ae
Compare
A Storybook has been deployed to preview UI for the latest push |
459c8ae
to
46d9fd6
Compare
A Storybook has been deployed to preview UI for the latest push |
46d9fd6
to
0ddec7c
Compare
params_dict.Set(kSiteURLField, report_url.spec()); | ||
params_dict.Set(kShieldsEnabledField, shields_enabled); | ||
params_dict.Set(kAdBlockSettingField, GetAdBlockModeString(ad_block_mode)); | ||
params_dict.Set(kFPBlockSettingField, | ||
GetFingerprintModeString(fp_block_mode)); |
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.
Could we define a struct for this data? I was going to let it slide since I figured it would be written directly to JSON, but that's not even the case 😛
Especially if we can expose that struct definition in a way so it can be shared with iOS, although it doesn't have to be in this PR.
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.
could you maybe elaborate? this is kind of hacky, but the JSON is passed to the dialog via the webui params (which is JSON), and then those same params are passed back to the UI handler upon submission (also via JSON). I haven't found a way to pass a struct directly from the "open dialog" function to the UI handler.
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.
Ah, I understand now. I was hoping we could have a custom struct as a constructor argument for the delegate, but the current one that takes base::Value
just directly sets params_
from the inherited class. Nevermind!
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.
yeah it's a shame. this is a pretty cringey way to pass data, to say the least....
} | ||
} | ||
|
||
ad_block_list_names_ = base::JoinString(ad_block_list_names, ","); |
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'd personally recommend using component IDs here for slightly easier machine-readability/consistency with the catalog in https://github.com/brave/adblock-resources (list names may change, infrequently). Then again, I'm not going to be the one looking at the raw report uploads 😄
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.
happy to change this if it would be more useful. as you know, all of our webcompat reports are displayed on our dashboard in a human readable format, for manual review. i assumed it would be more useful for an adblock/easylist dev to see the name of the list in this case, but please correct me if i'm wrong since I will also not be looking at the reports! 😄 . curious to hear your thoughts on my perspective
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 don't feel strongly about it. We'd be able to figure out what lists are referenced either way if reviewing raw upload data, and having the names directly available makes it easier to do so without any changes to the tooling.
The benefits of using the component IDs are
- fixed size/format
- constant identifier even if list names change
(1) is 100% a serverside implementation concern, so I have no preference there
(2) is slightly nicer for the sake of consistency in longer-term analysis, but we delete reports after 30 days anyways so it's not even too relevant either
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.
Thanks for elaborating. If using names would make report reviews easier, then I would prefer to go that route. From a server-side perspective, it's much easier for us to store the names, as we will not have to maintain a mapping of component IDs to list names which would increase query complexity, risk for mapping inconsistencies, etc. etc. The size of the field is not a concern, considering the low volume of reports (compared to the rest of the stats data we manage). If you think that potential name changes won't cause too much trouble, then I hope to keep this as is
A Storybook has been deployed to preview UI for the latest push |
0ddec7c
to
5e48387
Compare
A Storybook has been deployed to preview UI for the latest push |
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.
strings
++ (with a nit)
5e48387
to
1d316b5
Compare
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.
strings
++
A Storybook has been deployed to preview UI for the latest push |
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.
lgtm
just checking @DJAndries , are any needed updates to the privacy policy complete? And, will this affect android and desktop? Or just desktop? |
For this PR, just desktop |
since most of this doesn't have a UI component, what is needed to enable it on android too? |
not too much, i think. the changes required will basically be a duplicate of this PR, but in Java. Raised brave/brave-browser#33126 |
thanks thanks, though im surprised that Java is needed (again since there isn't a UI/UX component to the change) will follow up with the android experts. Thanks! |
Verification PASSED on
|
Uplift of #20052 (squashed) to beta
|
||
ad_block_list_names_ = base::JoinString(ad_block_list_names, ","); | ||
|
||
#if BUILDFLAG(ENABLE_BRAVE_VPN) |
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.
the UI code is not the correct place to put this because it's creating an unnecessary dependency from //brave/browser/ui
-> //brave/browser/tor
which already has deps issues and require check_includes = false. This should be encapsulated in another interface for report generation that only exposes a header target to //brave/browser/ui
* License, v. 2.0. If a copy of the MPL was not distributed with this file, | ||
* You can obtain one at https://mozilla.org/MPL/2.0/. */ | ||
|
||
#include "brave/components/webcompat_reporter/browser/fields.h" |
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.
why is this file named fields
? Also why does it even need to be public in the first place? It appears to only be called in WebcompatReporterDialog
Resolves brave/brave-browser#32661
Submitter Checklist:
QA/Yes
orQA/No
;release-notes/include
orrelease-notes/exclude
;OS/...
) to the associated issuenpm run test -- brave_browser_tests
,npm run test -- brave_unit_tests
wikinpm run lint
,npm run presubmit
wiki,npm run gn_check
,npm run tslint
git rebase master
(if needed)Reviewer Checklist:
gn
After-merge Checklist:
changes has landed on
Test Plan:
Use MITM proxy to ensure that all additional details are being appended to report.