brave / brave-browser Goto Github PK

We currently use 'allow' for content setting of ad-block which is confusing because you're allowing the ad-block of ads.

Instead change to content settings name of 'ads' and allow or block them.

Also it's an issue if you toggle on and off in sequence for top level shields, it clears the saved previous values of the sub-shield settings. This needs to be stored separately.

For reference:
https://github.com/brave/browser-android-tabs/commit/55fda525fd64a1f6539ea20b8a0a0ebe6a573533

Description:
Requested via community - user would like the ability to customize top site tiles on the new tab page:
https://community.brave.com/t/how-do-i-add-shortcuts-to-the-inicial-page/11277

Designs

Assets

Figma: https://www.figma.com/file/QqaIjdrXobryTT3Zd9wcKM/?node-id=0%3A1

Building on #32 but with Tor support

• Windows
• macOS

• Restyle bookmarks
• Restyle history
• Restyle preferences
• Downloads page

Chrome's Flash deprecation policy is here:
https://www.chromium.org/flash-roadmap

As of C68 we'll have:

Non-Persisted HTML5 by Default (Target: Chrome 68 - July 2018)
Summary
Sites using Flash will require explicit permission to run, every time the user restarts the browser.
Rationale
Require affirmative user choice to run Flash Player content, without that choice persisting across multiple sessions.

For the initial version that is OK.

We can diverge from the Disable by default (Chrome 76+ - July 2019) and Remove Flash completely ( Dec 2020) in separate issues.

Use Brave component updater for extension installation which will offer extensions from Brave's server.

The front end needs a way to get details of the JS resources which are blocked.

• Ledger wallet
• Bookmarks
• Cookies
• History

More?

Emphasis on MVP for something we'd be able to release as 1.0. This should be similar to what we have privacy wise with Muon. This is just a task for the audit itself.

• The front end needs a way to get details of the JS resources which are blocked.
• Finer grained control to pick which subresource origins to be temporarily allowed.

From community https://community.brave.com/t/navigate-between-pages-via-swipes/1863

+1 from me as well.

Add parity Brave features to what is in browser-laptop. Determine what we need above and beyond #15. We will likely move this to a new tab instead.

Currently it just downloads on each run.
It should use etags and conditionally download and check only on certain time intervals. See browser-laptop for reference.

Test Plan:

Visit http://https-everywhere.badssl.com/ in a new tab
Should automatically upgrade to https://https-everywhere.badssl.com/

Test plan

Run the test at https://www.aloodo.org/test/

https://github.com/google/omaha

• Make URL bar suggestions work from top 500
• Disable search suggestions by default always

You can find icon resources here:
https://github.com/brave/muon/tree/master/app/resources

Anthony started things here, and apparently it works for macOS.
https://github.com/brave/brave-browser/tree/multi-channel
https://github.com/brave/brave-core/tree/multi-channel

So still remaining is Linux and Windows.

You can see where we have different profile directories for each OS here:
brave/brave-core#46
brave/brave-core#59
This doc might be helpful:
https://chromium.googlesource.com/chromium/src/+/master/docs/user_data_dir.md

We want to support 4 channels:
release, beta, developer, and canary

User directory

For official build

• ~/Library/Application Support/BraveSoftware/Brave-Browser-Dev/Default for dev channel
• ~/Library/Application Support/BraveSoftware/Brave-Browser-Beta/Default for beta channel
• ~/Library/Application Support/BraveSoftware/Brave-Browser-Canary/Default for canary channel
• ~/Library/Application Support/BraveSoftware/Brave-Browser/Default for release channel

For unofficial build

• ~/Library/Application Support/BraveSoftware/Brave-Browser-Development/Default for all channel

TODOs

• channel option for build command (brave-browser)
• user dir support (brave-core)
  • MacOS
  • Windows
  • Linux
• install dir
  • MacOS
  • Windows
  • Linux
• app icon (brave-core)
  • MacOS
  • Windows
  • Linux

To keep in line with browser-laptop, all tab set options should be available

Repurpose multi user support for session windows.

importing bookmark, history, cookies, saved password from Chrome

Because Brave adds a lot of specific and important functionality over the Chrome base set, we need to pull the Brave shields and regroup them into Brave specific sections.

(then rename to match desktop and iOS in a second task)

Future sync items are shown but those will be defined separately.

• Restore tabs from last time
  ... todo: add more ...

Maybe have a content-script that inserts some popup div to direct people to the correct location?
Configure the allowed webstore URLs.

We would like to have a page showcasing extensions which are installable in the Brave browser. Users could visit this page, find extensions they're interested in, and then install them

Milestones

• Stand up a REST API around the store functionality. Used to fetch extension details
• Create the minimum HTML/JavaScript needed for a client page to call the REST API and show the results (even just if in a div)
• Get the client page using React (including Brave UI)
• Update client page with JavaScript needed to install an extension (one of the extensions being listed)
• If extensions are already installed, show a difference in the UI ("already installed")
• Have a details page available for each extension. This would route to a different URL like /store/extension-id-here. We'd want to be storing enough information to make this useful (ex: instead of just extension id, name, version- we should pull more fields)
• Componentize the UI code using React - use Brave UI where possible
• Create unit tests for the REST API
• Integrate a linter (ex: standard) with the project
• Setup a git pre-push hook to ensure lint/tests pass before a push is done

Taking this to the next level

There are a few things we could do to make this experience better which are definitely related, but should be captured in different issues.

• Updating extensions (perhaps by calling the REST API?)
• Adding new extensions get added to the store
• Vetting extensions for quality (ex: not malware, not making risky calls)
• Management interface for extensions (for our use- ex: used to approve/reject extensions)

Changelog file should have our own information
See: #12 (comment)