-
Notifications
You must be signed in to change notification settings - Fork 989
Add New tab page options to settings #6879
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
Conversation
9efd0e4
to
dd2f61e
Compare
dd2f61e
to
c809b7b
Compare
This setting seems to also apply to Private and Tor windows. Is this expected? |
c809b7b
to
6ecc6fe
Compare
@simonhong I think we only need to apply this to regular window - Private and Private w/ Tor windows both have the informational page that we would like to show |
6ecc6fe
to
391c5de
Compare
This option is only effective for normal window. |
391c5de
to
83f36e6
Compare
@rebron @bsclifton , one more question - Should |
83f36e6
to
58e0092
Compare
58e0092
to
1755ed9
Compare
Curious what you think @karenkliu @rebron To me, it makes more sense to put Unrelated to this PR, I think that |
Yes - this new setting should be checked/respected when opening a new window too 😄 Should we hide the |
@karenkliu and I chatted about this yesterday. Placement looks good. We should hide the homepage option until a user enables the homepage button. Otherwise, it won't really make sense. |
|
||
namespace chrome { | ||
|
||
// Whole logic is copied from upstream chrome::NewTab(). |
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.
Maybe also note as part of this comment:
// the only change is `new_tab_url` instead of `Gurl()`
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.
Code changes look really good! Notes left about how this should work on new window also
@karenkliu may have some comments too 😄
@simonhong Hi Simon, after going through the details again, these are some updates to the design:
|
@bsclifton @rebron What should we do in this scenario? IMO, making |
Agree with @simonhong that it would be more beneficial to have Homepage drop-down option visible not based on the Home Button setting, but rather on whether the homepage URL has been set. However, setting the Home URL is not well-discoverable in the settings right now. Why not always have the Homepage drop-down visible and, if selected, show to the user the entry field to set the URL (which would be tied to the same pref as the one under Home Button)? |
I'm OK with always showing |
@karenkliu When user select |
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.
Can remove the different resources for light and dark. I suggest we just use chrome://newtab and serve blank.html from there, but maybe there's a reason you created chrome://blank
<title>Blank page</title> | ||
</head> | ||
|
||
<body style="background-color:#FFFFFF;"> |
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.
We can put a <style>
element here which varies the background-color based on dark / light theme. Similar to on the dashboard NTP: https://github.com/brave/brave-core/blob/master/components/brave_new_tab_ui/brave_new_tab.html
@media (prefers-color-scheme: dark) {
body { background-color: #333639; }
}
Then we don't need both blank_page.html
and dark_blank_page.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.
Fixed 👍
class BraveBlankPageUI : public content::WebUIController { | ||
public: | ||
BraveBlankPageUI(content::WebUI* web_ui, | ||
const std::string& host); | ||
~BraveBlankPageUI() override; | ||
|
||
BraveBlankPageUI(const BraveBlankPageUI&) = delete; | ||
BraveBlankPageUI& operator=(BraveBlankPageUI&) = delete; | ||
}; |
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.
Instead of creating a whole new WebUI route and class, I was thinking we could just use the regular chrome://newtab
route and class, and simply change the .html resource that is rendered, depending on the value of kNewTabPageShowsOptions
. I can't think of a reason that we would need to have separate routes or both the dashboard route and the blank route available at the same time, regardless of the preference value. Do you have a different opinion?
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 thought new tab and blank are different webui. So, I created new route.
But, I don't have strong opinon about this. I'll follow your suggestion.
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.
@petemill Fixed. PTAL again!
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 realized that your approach is better because blank page can also act like NTP. - search suggestion in location bar.
const bool is_dark_mode = | ||
dark_mode::GetActiveBraveDarkModeType() == | ||
dark_mode::BraveDarkModeType::BRAVE_DARK_MODE_TYPE_DARK; |
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.
See comment about no need to vary on dark mode.
} else if (option == brave::NewTabPageShowsOptions::BLANKPAGE) { | ||
return GURL(url::kAboutBlankURL); | ||
return GURL(kBraveBlankPageURL); |
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.
see comment about not needing a separate route as far as I can tell
343a4c2
to
da0dfe9
Compare
81c3903
to
2a5be52
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 overrides LGTM
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.
Looks great to me apart from 1 html syntax error to fix
2a5be52
to
dcb29c8
Compare
dcb29c8
to
903c4c0
Compare
With this, user can select which page should be opened in NTP.
Also renamed dashboard with images to dashboard.
Instead of url rewriting, navigation throttle is used. When new tab url is requested, throttle cancels it if new tab options url should be used. With url rewriting, new tab options url loading is fine. However, tab title is not updated well if blank url is loaded.
This blank page will have different bg color for theme type. And new tab shows blank page options will use this page.
Blank page will be configured by BraveNewTabUI.
also fix some var name after c87 rebasing.
903c4c0
to
0713614
Compare
Merged because only unrelated rewards browser test are failed. |
With this, user can select which page should be opened in NTP.
dark mode blank page:

Resolves brave/brave-browser#2999
Submitter Checklist:
npm run lint
,npm run gn_check
)git rebase master
(if needed).git rebase -i
to squash commits (if needed).QA/Yes
orQA/No
) to the associated issuerelease-notes/include
orrelease-notes/exclude
) to the associated issueTest Plan:
npm run test brave_unit_tests -- --filter=*BraveNewTabTest*
Reviewer Checklist:
After-merge Checklist:
changes has landed on.