[NTP Next] Add updated NTP with background support

[zenparsing]

Resolves brave/brave-browser#42298

Submitter Checklist:

• I confirm that no security/privacy review is needed and no other type of reviews are needed, or that I have requested them
• There is a ticket for my issue
• Used Github auto-closing keywords in the PR description above
• Wrote a good PR/commit description
• Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
• Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
• Checked the PR locally:
  • npm run test -- brave_browser_tests, npm run test -- brave_unit_tests wiki
  • npm run presubmit wiki, npm run gn_check, npm run tslint
• Ran git rebase master (if needed)

Reviewer Checklist:

• A security review is not needed, or a link to one is included in the PR description
• New files have MPL-2.0 license header
• Adequate test coverage exists to prevent regressions
• Major classes, functions and non-trivial code blocks are well-commented
• Changes in component dependencies are properly reflected in gn
• Code follows the style guide
• Test plan is specified in PR before merging

After-merge Checklist:

• The associated issue milestone is set to the smallest version that the
  changes has landed on
• All relevant documentation has been updated, for instance:
  • https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)
  • https://github.com/brave/brave-browser/wiki/Proxy-redirected-URLs
  • https://github.com/brave/brave-browser/wiki/Fingerprinting-Protections
  • https://github.com/brave/brave-browser/wiki/Brave%E2%80%99s-Use-of-Referral-Codes
  • https://github.com/brave/brave-browser/wiki/Web-Compatibility-Exceptions-in-Brave
  • https://github.com/brave/brave-browser/wiki/QA-Guide
  • https://github.com/brave/brave-browser/wiki/P3A

Test Plan:

[brave-builds]

A Storybook has been deployed to preview UI for the latest push

[bridiver]

you don't need a common directory here since this is browser process only, just put everything in the root. Also there is inconsistent naming here, sometimes brave_new_tab and sometimes new_tab_page in other places. brave_new_tab_page is probably best I think

[bridiver]

also not really sure that it makes sense to put any of this code in components unless. I would just put this code in brave/browser/ui/webui/brave_new_tab_page and put the resources in brave/browser/resources/brave_new_tab_page to match upstream

[zenparsing]

I've moved all of the code out of components as suggested - thanks! Naming is TBD.

[zenparsing]

I've updated the folder names, file names, and namespace name. I think naming is in a good place now.

[zenparsing]

I've moved the resource code back into components/brave_new_tab, as the suggested change resulted in naming conflicts with the existing NTP. Follow-up issue created here: brave/brave-browser#42563

[bridiver]

Maybe you haven't got back to this yet, but as discussed this should be new_tab_page/brave_new_tab_* with no namespace. The existing file/directory is already correct (for some reason I thought it was different) so the flag should be internal to it as is normally the case for this kind of thing.

[zenparsing]

Follow up issue for folders/namespacing: brave/brave-browser#42563

[github-actions]

Chromium major version is behind target branch (131.0.6778.85 vs 132.0.6834.15). Please rebase.

[fallaciousreasoning]

This is looking great @zenparsing - awesome work 😄

Sorry its taken so long to review!

[fallaciousreasoning]

Hey do you think it would be useful to pass the change in here? At the moment, when you change something there are quite a few mojom round trips:

1. Send a message to update the pref
2. Receive a notification it changed from the pref handler
3. Send a new message to the tab handler asking about the new values
4. Receive the result

[zenparsing]

You're right - this can be optimized. The easiest next step would be to provide the pref name (as an enum value perhaps?) and let the front end decide what to update. I think we should leave this optimization for later, since it will take some thinking through (and it's hard to tell whether it's worth it).

[fallaciousreasoning]

Okay, happy to leave this for now. One thing to keep in mind is that it does somewhat simplify the mojom interface, as you no longer need to provide getters for any of the values (you just fire the change listener when its added). I've found the pattern makes it a bit easier to reason about where stuff comes from.

If you didn't want to add a separate listener for each different channel, you could just add all the fields into the callback

OnBackgroundPrefsUpdates(Thing1 thing1, Thing2 thing2, ..., ThingN thingN)

and you can simplify some of your initialization logic (instead, we just add ourselves as a listener and are notified of the current state + any changes that happen later).

[zenparsing]

I see that we've been moving some mojo interfaces toward a push-only API. I think that the most flexible setup is a hybrid where data is pulled and update notifications are pushed. It does require more round-trips and possibly more interface methods, however. I'll keep this in mind as we move through the project - the hybrid approach is not yet set-in-stone.

[fallaciousreasoning]

Hey @zenparsing, the PR is looking great - I'm approving

Do you mind updating & resolving (with whatever you decide) these comment threads:

• [NTP Next] Add updated NTP with background support #26408 (comment)
• [NTP Next] Add updated NTP with background support #26408 (comment)

Thanks for all the work you've put into this! I'm going to be on PTO for a few weeks so probably best to reach out to @petemill if anything comes up 😄

[github-actions]

[puLL-Merge] - brave/brave-core@26408

Description

This PR introduces a new version of the New Tab Page (NTP) for Brave Browser. It includes a redesigned UI with customizable background options, including Brave backgrounds, custom user backgrounds, solid colors, and gradient backgrounds. The PR also adds support for sponsored images and implements a settings panel for managing these background options.

Possible Issues

1. The new NTP implementation might not have feature parity with the existing one, potentially leading to user confusion or missing functionality.
2. Performance implications of loading and rendering background images, especially for users with slower devices or connections, should be carefully considered.

Security Hotspots

1. URL sanitization in url_sanitizer.ts: Ensure that all external URLs (e.g., for background image links) are properly sanitized to prevent potential XSS or other injection attacks.
2. Custom background image handling: Validate and sanitize user-uploaded images to prevent malicious file uploads or execution.

Changes

Changes

1. browser/brave_content_browser_client.cc:

   • Added binding for the new NewTabPageHandler.

2. browser/brave_profile_prefs.cc:

   • Updated NTP preferences registration to use new brave_new_tab::prefs.

3. browser/new_tab/:

   • Modified new_tab_shows_options.cc and new_tab_shows_options.h to use the new brave_new_tab::prefs.

4. browser/ui/webui/brave_new_tab/:

   • Added new files for handling the new NTP UI, including background_adapter.cc, custom_image_chooser.cc, new_tab_page_handler.cc, new_tab_page_ui.cc, and update_observer.cc.

5. components/brave_new_tab/:

   • Added new directory with files for the new NTP implementation, including models, features, and preferences.

6. components/brave_new_tab/resources/:

   • Added new React components, styles, and utilities for the redesigned NTP UI.

7. components/brave_new_tab_ui/:

   • Updated build files and renamed some resources to avoid conflicts with the new implementation.

8. components/constants/pref_names.h:

   • Removed kNewTabPageShowsOptions constant.

9. components/resources/:

   • Updated build files and resource packs to include the new NTP resources.

sequenceDiagram
    participant User
    participant NTP as New Tab Page
    participant Handler as NewTabPageHandler
    participant Model as NewTabModel
    participant BG as BackgroundAdapter

    User->>NTP: Open New Tab
    NTP->>Handler: Initialize
    Handler->>Model: Create NewTabModel
    Model->>BG: Get background info
    BG-->>Model: Return background data
    Model-->>NTP: Update UI with background
    NTP->>User: Display New Tab Page
    User->>NTP: Interact with settings
    NTP->>Handler: Update preferences
    Handler->>Model: Update state
    Model->>BG: Apply changes
    BG-->>Model: Confirm changes
    Model-->>NTP: Reflect updated state
    NTP->>User: Show updated New Tab Page

Loading