-
Notifications
You must be signed in to change notification settings - Fork 920
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
[NTP Next] Create WebUI scaffolding #27780
base: master
Are you sure you want to change the base?
Conversation
// 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/. | ||
|
||
module brave_new_tab_page_refresh.mojom; |
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.
you don't really need the namespace here if you don't want it since the types in the other files in this dir don't have one
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 feel like it might be asking for trouble to have names defined here put into the global namespace?
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.
There is precedent in chromium. It's the same problem if we name something too generically in a .h file, isn't it? So as long as we name everything NewTabPageXYZ it should be fine. You could leave the line as module mojom;
if you want it in a mojom::
global namespace, or you could omit it entirely for global namespace. Just a suggestion as I know you had an issue with the frequent repetition of namespaces in the c++.
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.
My would be for brave_new_tab_page_refresh.mojom
but it probably is worth being consistent (and the other files aren't in a namespace)
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.
It's absolutely ok to keep the namespace here. I was just giving the option because I remember it was a complaint of having to write the namespace everywhere if the C++ doesn't have the same namespace.
#include "mojo/public/cpp/bindings/receiver.h" | ||
#include "mojo/public/cpp/bindings/remote.h" | ||
|
||
namespace brave_new_tab_page_refresh { |
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 forgot that this namespace was in here. However, if I remove the namespace and rename this class BraveNewTabPageHandler
, then I get a conflict with the existing BraveNewTabPageHandler
.
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.
Then perhaps we can temporarily add the Refresh word in to the name? It's probably only going to be referenced outside of this class once or twice.
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 have a slight preference for namespacing everything but upstream definitely doesn't, so I'm fine with Pete's suggestion - I'd rather we be consistent
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 can't speak to whether the brave_chrome_browser_allow_circular_includes_from
part is ok, but the rest seems inline with what we discussed
A Storybook has been deployed to preview UI for the latest push |
// 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/. | ||
|
||
module brave_new_tab_page_refresh.mojom; |
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.
My would be for brave_new_tab_page_refresh.mojom
but it probably is worth being consistent (and the other files aren't in a namespace)
#include "mojo/public/cpp/bindings/receiver.h" | ||
#include "mojo/public/cpp/bindings/remote.h" | ||
|
||
namespace brave_new_tab_page_refresh { |
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 have a slight preference for namespacing everything but upstream definitely doesn't, so I'm fine with Pete's suggestion - I'd rather we be consistent
0a4f0f6
to
0bb44e6
Compare
browser/about_flags.cc
Outdated
@@ -535,6 +535,13 @@ const flags_ui::FeatureEntry::FeatureVariation kZCashFeatureVariations[] = { | |||
kOsDesktop, \ | |||
FEATURE_VALUE_TYPE(features::kBraveNtpSearchWidget), \ | |||
}, \ | |||
{ \ | |||
"brave-use-updated-ntp", \ | |||
"Use the updated New Tab Page", \ |
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.
please use consistent naming (refresh instead updated). Also kBraveNewTabPageRefreshEnabled
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.
@@ -633,3 +635,11 @@ if (is_android) { | |||
"//brave/browser/android:tab_features", | |||
] | |||
} | |||
|
|||
# TODO(https://github.com/brave/brave-browser/issues/43310): | |||
# brave_new_tab_page_ui.cc includes some headers (e.g. from |
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.
Ugh, another variation (new_tab vs new_tab_page). In any case this seems trivial to move new_tab_shows_options.h/new_tab_shows_options.cc to a separate target inside //brave/browser/BUILD.gn
? Or is there something else as well?
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've updated the linked issue to include the current list of circular includes for the NTP next prototype. They are:
brave/browser/new_tab/new_tab_shows_options.h
chrome/browser/ntp_tiles/chrome_most_visited_sites_factory.h
brave/browser/brave_vpn/brave_vpn_service_factory.h
There may be more (some features aren't yet implemented in the prototype). Unfortunately, I don't think it will be pragmatic to chase these down in the context of this project.
b393945
to
14efb1b
Compare
14efb1b
to
1447814
Compare
Resolves
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 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: