To solve webcompat problems we replace forcing "no-referrer"
for cross-site top-level navigations with capping with
"strict-origin-when-cross-origin".
Fix https://github.com/brave/brave-browser/issues/13464
This change adds a new class EphemeralStoragePartition which provides
access to an ephemeral version of a RestrictedCookieManager for the
content process. In an upcoming change this will also provide a
StoragePartition for navigation requests in third-party frames in order
to add support for navigation cookies.
Ephemeral storage persists DOM storage in third-party frames in a
partitioned storage area that is unique to each top-level frame eTLD.
The storage area is persisted until no tabs from the top-level eTLD
exist.
This change also adds a runtime flag for ephemeral storage, which is
only useful if third-party storage is activated. A future change will
selectively enable third-party storage when the flag is active.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/7f6955321792ce372e935f49cd4420b5b6ecb15f
commit 7f6955321792ce372e935f49cd4420b5b6ecb15f
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Tue Sep 15 16:05:22 2020 +0000
Make WebUIURLLoaderFactory always owned by its |receivers_|.
This CL changes (and slightly renames) CreateWebUIURLLoaderFactory so
that it returns mojo::PendingRemote to a WebUIURLLoaderFactory that is
owned by its |receivers_| and will self-delete when the last receiver
disconnects.
This CL removes the ability to directly construct and own a
std::unique_ptr<WebUIURLLoaderFactory>, because this ability means that
the factory can be destructed while receivers bound via the Clone method
are still alive (see the associated bug).
This CL mostly just follows the pattern established earlier by
https://crrev.com/c/2337411.
Bug: 1106995
These files have been relocated into //content/browser/renderer_host now,
so we need to update the relevant patches and their filenames.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/c492bf822b4b44da5bbfb8ab4997333165ededd0
commit c492bf822b4b44da5bbfb8ab4997333165ededd0
Author: danakj <danakj@chromium.org>
Date: Wed Sep 9 20:02:44 2020 +0000
Move content/browser/frame_host/* over to content/browser/renderer_host/
We allow these directories to work together now and have decided to
merge them to simplify understanding the code relationships.
Add forwarding headers in content/browser/frame_host/ to make this
transition easier. PRESUBMIT and tricum errors are not addressed in this
CL as it is just moving code.
TBR=avi@chromium.org
Bug: 1091083
It has been moved from Blink's public/mojom into public/mojom/loader,
so we need to update include paths.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/60693aa5a0a281ba33d7ad08da48dc8170288983
commit 60693aa5a0a281ba33d7ad08da48dc8170288983
Author: Hiroki Nakagawa <nhiroki@chromium.org>
Date: Thu Jul 16 09:01:41 2020 +0000
Loader: Move referrer.mojom into blink/public/mojom/loader
blink/public/mojom/loader is a more suitable place for referrer.mojom
than the Blink's top-level mojom directory (i.e., blink/public/mojom) in
terms of code structure.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/09d6c765735cf60555dae5780aff8cfa14d7cb7d
Stop passing Navigator into each FrameTreeNode.
They were all getting a reference to the same object. Instead, let them
all access it via the FrameTree.
Make Navigator a direct member of FrameTree, accessed as a reference
since it cannot be null.
This is a mechanical change apart from web_contents_impl.cc:4645
which removes what looks like pointless pointer chasing to get to the
NavigationController.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/37109f21fbbeece29c5eb75f5a3ac3f0caa7a20a
commit 37109f21fbbeece29c5eb75f5a3ac3f0caa7a20a
Author: jessing <jessing@google.com>
Date: Mon Feb 3 01:59:20 2020 +0000
[system-web-apps] Add ability to grant requestable schemes in a WebUI
Currently chrome:// URLs are not allowed to embed chrome-untrusted://
URLs because we never grant request access to chrome-untrusted:// URLs.
To allow for this, this CL makes a couple of changes (Note that this is
only fixes the issue on the browser side. The renderer still has some
checks that stop us from loading chrome-untrusted:// iframes.):
1. Make the set of requestable schemes part of content::WebUI. This way
clients of WebUI can control which additional schemes they want their
WebUI to be able to request. The function to add a scheme is added as a
webUI API because it is expected to be used by chrome/ WebUIControllers
that use chrome-untrusted://.
2. When creating a WebUI in RenderFrameHostImpl::CreateWebUI(), grant
request access to the schemes the WebUI specified.
3. Decouple granting access to chrome:// and file:// from
ChildProcessSecurityPolicy::GrantWebUIBindings(). Instead add this to
the list of schemes in content::WebUIImpl. Long term, we should be able
to remove these schemes from content::WebUIImpl and instead have each
client specify the schemes they want access to, similarly to how
clients will call EnableMojoJsBindings()[1].
[1] https://cs.chromium.org/chromium/src/content/browser/process_internals/process_internals_ui.cc?l=53&rcl=0ab24b983b19f971f40b2f1e3f5a5b95c7a1ad9a
Bug: 1043548
It was removed because it became no longer used.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/a4d27f513eb40a89505f042d68693ed6702400d9
commit a4d27f513eb40a89505f042d68693ed6702400d9
Author: Ken Rockot <rockot@google.com>
Date: Thu Dec 5 03:13:14 2019 +0000
Move Audio Service off Service Manager
All the details around if/when a service instance is started and whether
it's in- or out-of-process have been centralized into the implementation
of a single GetAudioService() helper in Content.
A few other helpers are added to ease the transition off the Service
Manager, though they aren't necessarily ideal APIs. For example,
client library APIs which once took a Service Manager Connector may now
take a RepeatingCallback to bind a specific type of interface.
In addition to GetAudioService(), Content provides helpers for
AudioSystem construction and StreamFactory binding from any sequence.
Because all timeout/lifetime management logic is now generically
supported within Mojo and Content and requires no service implementation
details to get right (and because unit tests launching service processes
is no longer supported outside of Content), all Audio Service test
coverage relevant to lifetime management is deemed superfluous and has
been removed.
Bug: 977637
Chromium change:
https://chromium.googlesource.com/chromium/src/+/25f8a22ada1c17c3724ddfd0a850daaf4410b8e2
commit 25f8a22ada1c17c3724ddfd0a850daaf4410b8e2
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Tue Jan 14 16:20:07 2020 +0000
Reland "Add internals.setPermission() and permission_automation.mojom."
This is a reland of e7a6d173632660b6aeb9806e9132c34a315331c2, which got
reverted due to crashes in ChromeOS and Android caused by
ENABLE_PROTECTED_MEDIA_IDENTIFIER_PERMISSION not being defined in
PermissionDescriptorToPermissionType()'s new location in
//content/public/browser. This reland now moves the setting of this macro
from //content/browser/BUILD.gn to //content/public/browser/BUILD.gn (that
function is the only user of this macro).
Original change's description:
> Add internals.setPermission() and permission_automation.mojom.
>
> web-platform-tests has recently gained the ability to set the permission
> associated to a permission type via test_driver.set_permission(), in a
> similar fashion to Blink's testRunner.setPermission().
>
> This is CL #1 of a few, and the ultimate goal is to add an implementation of
> set_permission() to testdriver-vendor.js, so that we can replace uses of
> testRunner.setPermission(), and consequently move more Blink-specific tests
> to WPT.
>
> This CL adds a new .mojom file to third_party/blink/public/mojom/permissions
> that allows setting the permission associated with a given permission type,
> in a similar fashion to testRunner.setPermission(). This API is only
> intended for use in tests, so the new PermissionAutomation interface is
> added to a separate file that is part of the blink.test.mojom module, and it
> is only implemented by content_shell. It then plugs it into the internals
> object. While in the short term it adds another way to achieve the same
> thing in layout tests, this was done for a couple of reasons:
>
> * test_driver.set_permission() takes a PermissionDescriptor (from the
> Permissions API) rather than a string that does not necessarily match the
> permission name as specified in the Permissions API.
> It makes sense to use standardized APIs, so rather than adding code to
> convert a PermissionDescriptor into a string accepted by testRunner's
> setPermission(), internals.setPermission() also takes a
> PermissionDescriptor.
> * Since testRunner is implemented entirely in //content/shell, we cannot
> have its code call Blink to convert a JS value representing the descriptor
> into a blink::mojom::PermissionDescriptorPtr. By Onion Soup'ing the code
> to set permissions, we can do all the PermissionDescriptor parsing in
> Blink and just call the PermissionAutomation implementation in content
> shell's browser side. For this, we change the internals object in Blink
> and bypass testRunner altogether.
> * The new API also gives us more flexibility: it returns a promise so that
> we can be sure the permission changes really have an effect before
> executing the rest of the code in a test.
>
> A few layout tests have been converted to the new API to show it works.
>
> Once existing uses of testRunner.setPermission() are converted, we can
> remove it altogether, and have internals.setPermission() be part of the
> implementation of testdriver.js' set_permission() call.
>
> Bug: 1030663
net::CookieOptions param is no longer passed to CanonicalCookie::Create.
We used this param's exclude_httponly() method to adjust expiration
time.
Patched back the param everywhere CanonicalCookie::Create is called,
which is not a great solution.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/b851acc052ee6a505d4f60fb9cc326c410b1285b
commit b851acc052ee6a505d4f60fb9cc326c410b1285b
Author: Lily Chen <chlily@chromium.org>
Date: Wed Aug 7 15:54:44 2019 +0000
Split server_time out of net::CookieOptions
CookieOptions had an optional server_time field, which was used for
clock skew adjustments when creating a cookie, and nothing else.
Since CanonicalCookie::Create no longer depends on the other fields of
CookieOptions, this CL replaces its CookieOptions argument with a
base::Optional<base::Time> server_time argument. The server_time field
is removed from CookieOptions because nothing else needs it. This does
mean that CookieStore::SetCookieWithOptionsAsync needs an additional
server_time argument since CookieOptions no longer includes it. But
that method needs to be removed anyways.
Mostly but not entirely mechanical changes. This should not change any
behavior.
Bug: 989098
As part of the conversion params referrer was converted from
content::Referrer to network::mojom::Referrer. Updated our
MaybeHideReferrer method to take mojom param.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/ef8290afc569e8ad87bb8b921f97827018f30031
commit ef8290afc569e8ad87bb8b921f97827018f30031
Author: Lucas Furukawa Gadani <lfg@chromium.org>
Date: Mon Jul 29 20:27:51 2019 +0000
Convert content::CommonNavigationParams to mojom.
Bug: 984550
We patch NavigationRequest::OnStartChecksComplete to call
MaybeHideReferrer. One of the params to MaybeHideReferrer is top
document GURL which was available in OnStartCheckComplete. The Chromium
change below removed it. Added a chromium_src override that includes
GetTopDocumentGURL function that containes the deleted functionality.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/435bcb58bb2c75be8276f1dde69fc6c9891c45ba
commit 435bcb58bb2c75be8276f1dde69fc6c9891c45ba
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Fri Jul 12 20:50:06 2019 +0000
Store |initiator_origin| in FrameNavigationEntry.
Changes in this CL
==================
This CL:
1. Updates FrameNavigationEntry::UpdateEntry and
FrameNavigationEntry's constructor so that they both take
|const base::Optional<url::Origin>& initiator_origin| which
gets stored in a new FrameNavigationEntry::initiator_origin_ field.
2. Updates callers of FNE::UpdateEntry and FNE's constructor to
provide/propagate the initiator as needed. This includes
adding an |initiator_origin| parameter to
- NavigationEntryImpl's constructor
- NavigationEntryImpl::AddOrUpdateFrameEntry
- NavigationController::CreateNavigationEntry
(the list above is not necessarily exhaustive/complete)
3. Uses the new |FrameNavigationEntry::initiator_origin()| from
NavigationEntryImpl::ConstructCommonNavigationParams (which
used to always provide |base::nullopt| initiator for history
navigations - always treating them as browser-initiated, rather
than replaying the original initiator).
The changes above makes sure that the right Sec-Fetch-Site http request header is
"replayed" during history navigations. The CL adds browser tests and
WPT tests to cover the new, desired behavior.
Follow-up changes
=================
This CL does not:
- Use |FrameNavigationEntry::initiator_origin()| in GetOriginForURLLoaderFactory
in render_frame_host_impl.cc (this will be done in a follow-up CL at
https://crrev.com/c/1672176)
- Handle persisting |FrameNavigationEntry::initiator_origin()| for
session restore (this is tracked in a separate https://crbug.com/976055).
Bug: 946503
Swith over an enum needed to have Brave enum values added since it
doesn't use default clause.
Chromium change:
commit 5afc73e3e0b6605251b86e49abb0e02a2a7294ac
Author: Alexander Timin <altimin@chromium.org>
Date: Mon Jun 24 01:03:10 2019 +0000
[bfcache] Track permissions in the browser process.
It turns out that the renderer-side tracking doesn't cover all the use
cases we want to cover.
Move the tracking the browser side:
- Add an API for the browser code to notify us about the feature usage.
- Add a test for the new API.
- Move permission tracking logic into the browser process.
- Add a test for geolocation tracking.
R=clamy@chromium.org,arthursonzogni@chromium.org,lowell@chromium.org,mlamouri@chromium.org
BUG=977885
So far, brave only exposes flash when it is available.
Brave will use pdfium as a pdf viewer instead of pdf.js.
That causes plugins and mimeTypes will include pdf things.
That means we expose all that brave have.
So, we don't need to blacklist except flash plugins.
The functionality was called from override of
ChromeBrowserMainParts::PreShutdown, which was removed along with the
call to it from BrowserMainLoop::PreShutdown. This fix subclasses
BrowserMainLoop and calls BraveBrowserMainParts::PreShutdown from it.
It also patches BrowserMainParts to add virtual PreShutdown method
and BrowserMainRunnerImpl to instantiate BraveBrowserMainLoop instead
of BrowserMainLoop.
Chromium change:
commit 0f15e7a22545884fd259b873366a511686f4e5d9
Author: Alexei Filippov <alph@chromium.org>
Date: Thu Feb 14 21:34:28 2019 +0000
[heap profiler] Migrate UMA heap profiler off LegacyCallStackProfileBuilder
... and remove the latter as it was the last client.
BUG=916303,913570
To fix this, brave scheme is registered to WebSecurityPolicy and
RequestScheme of ChildProcessSecurityPolicy::SecurityState.
Also, makes ProfileIOData::IsHandledProtocol consider brave scheme.
fix https://github.com/brave/brave-browser/issues/1387
- Main hamburger menu in non-Tor windows:
New private window with Tor
- Context menu for right-click on links:
Open link in private window with Tor
This pushes IsTorProfile() into BrowserContext where it now resides
alongside IsOffTheRecord(), since we need it in order to determine
whether the 'Open link in private window with Tor' item should be
greyed out or not. (Is this a little silly? Maybe, but it's what the
browser already does with 'Open link in incognito window' item.)
Test plan:
1. 1. Open a fresh browser instance.
2. Confirm that hamburger -> 'New private window with Tor' (NPWWT)
opens a private window with Tor.
3. In the _Tor_ window, open <https://check.torproject.org/>.
4. Confirm that you are using Tor.
5. Right-click any link on the page.
6. Confirm that items to open in a private window, with or without
Tor, are greyed out.
7. Confirm that in the _normal_ window's hamburger, NPWWT switches
to the private window with Tor it just opened.
8. Confirm that in the _Tor_ window's hamburger, 'New window' opens
a new private window with Tor.
9. Confirm that in the _Tor_ window's hamburger, there is no NPWWT.
3. 1. Open a fresh browser instance.
2. In a _normal_ window, open <https://www.example.com/>.
3. Right-click the 'More information...' link.
4. Select 'Open link in private window with Tor'.
5. Confirm that the link opens in a Tor window.
6. In the normal window, do it again.
7. Confirm that the link opens in a new tab in the existing Tor
window.
TODO: Rename IsTorProfile to make more sense for BrowserContext.
Mario Sanchez Prada