-
Notifications
You must be signed in to change notification settings - Fork 906
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 Rewards settings to brave://settings #10610
Conversation
ceb35b8
to
68d3e9a
Compare
c8f41e1
to
c293127
Compare
} | ||
|
||
void RewardsDOMHandler::OnPreferenceChanged(const std::string& key) { | ||
AllowJavascript(); |
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.
Without changing anything else, we should probably no-op if we don't currently "allow" JS. Separately, I think the desired pattern is to only have observers registered from the JavascriptAllowed
method.
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 yes, fixed.
void RewardsDOMHandler::OnPreferenceChanged(const std::string& key) { | ||
AllowJavascript(); | ||
GetEnabledInlineTippingPlatforms(base::Value::ConstListView()); | ||
GetAutoContributionAmount(base::Value::ConstListView()); |
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.
By calling these message handlers directly, we're more-or-less acting on behalf of the front-end code. I don't have a strong opinion on that, but consider the tradeoffs of this versus the alternative that has the front-end listen for a generic "pref change" message and trigger these calls itself.
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.
That's a really good point. Updated as you suggested.
pref="{{prefs.brave.rewards.inline_tip.github}}"> | ||
</settings-toggle-button> | ||
</template> | ||
<template is="dom-if" if="[[!isRewardsEnabled_(prefs.brave.rewards.enabled.value, prefs.brave.brave_ads.enabled.value)]]" restamp> |
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.
Is it possible to just use prefs.brave.rewards.enabled
?
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.
Yes, meant to fix this - thank you!
export class BraveRewardsBrowserProxyImpl { | ||
/** @override */ | ||
isRewardsEnabled () { | ||
return new Promise((resolve) => chrome.braveRewards.shouldShowOnboarding( |
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.
FYI: there's also a chrome.braveRewards.getRewardsEnabled
function for just getting that pref (if you even need that from the settings page).
I would like to see us deprecate shouldShowOnboarding
(and certainly not use it here), because its usage is not well-defined. It looks like for this use case we should just be able to use the rewards.enabled pref directly (since it just controls whether the "params" are downloaded)?
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.
Does relying on rewards.enabled
introduce any backwards-compatibility problems? I'm sort of forgetting how these all changed over time. Totally agree that relying on the onboarding key is no good, so I did make this change.
c293127
to
a547199
Compare
@@ -0,0 +1,2 @@ | |||
<link rel="href" src="chrome://resources/html/cr.html"> |
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.
This file isn't neccessary
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, removed.
disabled="[[!prefs.brave.rewards.ac.enabled.value]]"> | ||
</settings-toggle-button> | ||
<div class="settings-box continuation"> | ||
<p>$i18n{braveRewardsAutoContributeDescLabel} <a href="https://brave.com/terms-of-use/" target="_blank" rel="noopener">Terms of Service</a> and <a href="https://brave.com/privacy/browser/" target="_blank" rel="noopener">Privacy Policy</a>.</p></p> |
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.
Should the end of the sentence " Terms of Service and Privacy Policy." not be translated too? This might come out in a weird order in some languages.
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.
Yes, good catch - fixed.
|
||
ready() { | ||
super.ready() | ||
this.openRewardsPanel_ = this.openRewardsPanel_.bind(this) |
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.
Perhaps you can use arrow function instead? openRewardsPanel_ = () => {
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.
Yup, done.
ready() { | ||
super.ready() | ||
this.openRewardsPanel_ = this.openRewardsPanel_.bind(this) | ||
this.maxAdsToDisplay_ = [ |
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.
Thses 4 variables can be instance variables declared outside the ready()
constructor? Or even global static variables?
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.
Done.
} | ||
|
||
shouldAllowAdsSubdivisionTargeting_() { | ||
return navigator.language === 'en-US' |
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.
Should this come from the backend API? Is there a possibility of navigator.language being different than the backend locale logic?
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 point, added a function to the backend API.
64ef4bd
to
70f1046
Compare
70f1046
to
af0f90a
Compare
af0f90a
to
a823c45
Compare
@@ -285,6 +287,9 @@ class RewardsDOMHandler | |||
// AdsServiceObserver implementation | |||
void OnAdRewardsChanged() override; | |||
|
|||
void InitPrefChangeRegistrar(); | |||
void OnPreferenceChanged(const std::string& key); |
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.
nit: OnPrefChanged
to be consistent with Chromium
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.
Fixed.
base::Unretained(this))); | ||
} | ||
|
||
void RewardsDOMHandler::OnPreferenceChanged(const std::string& key) { |
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.
nit: rename key
to path
to match components/prefs/pref_change_registrar.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.
Sure, fixed.
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
Not related directly to this PR. However, when we add subdivision targeting for Canada (brave/brave-browser#16682) "State-level ad targeting" will no longer make any sense for Canadian users (or other users when this feature is rolled out to other countres). We should look at rewording to "Subdivision-level ad targeting" as defined by the following https://en.wikipedia.org/wiki/ISO_3166-2 which is the universal naming convention. cc @Miyayes @jsecretan |
Makes sense from standards perspective (since Canada has provinces, Japan has prefectures, etc.), but from user perspective, I think the word "subdivision-level" could be quite confusing. Users would quickly understand once they see the list of provinces, of course, but I have never heard it used before. @rmcfadden3 might have some useful suggestions for generic wording. Edit: We may just go with translations for each region. |
@Miyayes I agree. But in the United Kingdom we call them Counties, so if this feature was ever rolled out to the UK then states would be even more confusing in my opinion |
b4fa4ea
to
99097c6
Compare
BraveRewardsGetLocaleFunction::~BraveRewardsGetLocaleFunction() {} | ||
|
||
ExtensionFunction::ResponseAction BraveRewardsGetLocaleFunction::Run() { | ||
const std::string locale = |
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.
Nit:
std::string locale = brave_l10n::LocaleHelper::GetInstance()->GetLocale();
return RespondNow(OneArgument(base::Value(std::move(locale))));
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, fixed.
5bad17b
to
84588e3
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.
LGTM
</div> | ||
</template> | ||
<div class="settings-box continuation"> | ||
<p>$i18n{braveRewardsStateLevelAdTargetingDescLabel} <a href="https://support.brave.com/hc/en-us/articles/360026361072-Brave-Ads-FAQ" target="_blank" rel="noopener">Learn more</a></p> |
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.
"Learn more" should be a part of a localizable string, or better - replace it with $i18n{learnMore}
.
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 catch, fixed.
84588e3
to
4532a32
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.
++ chromium_src
Resolves brave/brave-browser#18158
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
,npm run lint
,npm run gn_check
,npm run tslint
git rebase master
(if needed)Reviewer Checklist:
gn
After-merge Checklist:
changes has landed on
Screenshot:
Test Plan: