Comments

[IndexedDB] Histogram how often we actually use the base::CopyFile optimization.
Mostly maybe this is used so infrequently that we could just get rid of
it and do something simpler through the blob mojom interface.
Bug: 764130
Change-Id: I8197e0eca9199ed1311b867f44a590b91252db8f
Reviewed-on: https://chromium-review.googlesource.com/c/1476181
Commit-Queue: Mark Pearson <mpearson@chromium.org>
Reviewed-by: Mark Pearson <mpearson@chromium.org>
Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Auto-Submit: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#633479}

Comments

Crostini: Include header file instead of cc file
Instead of a header file, crostini included
chrome/browser/platform/platform_util_chromeos.cc which kind
of worked but in some builds triggered link failures later
because of duplicate symbols.
This probably works sometimes because nobody else uses the symbols
in platform_util_chromeos.o so that it is discarded before the linker
notices the duplication. Not always though.
Bug: 912638
Change-Id: I9b96a41e20ab5362fe800b502d788c844ac4d7f2
Reviewed-on: https://chromium-review.googlesource.com/c/1477025
Auto-Submit: Daniel Bratell <bratell@opera.com>
Commit-Queue: Timothy Loh <timloh@chromium.org>
Reviewed-by: Joel Hockey <joelhockey@chromium.org>
Reviewed-by: Timothy Loh <timloh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#633471}

Comments

Fix to show context menu icons on crostini shelf items.
There are two parts to this:
- needed to change the call in the menu builder to the version that
tries to find an icon.
- needed to add an entry for the icon that will be used by the
shutdown menu item, currently we use the uninstall icon as a
placeholder.
Bug: 930869
Change-Id: I6921eb175fe41b8239d098435dd933fd806a72cb
Reviewed-on: https://chromium-review.googlesource.com/c/1472015
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Reviewed-by: Nicholas Verne <nverne@chromium.org>
Commit-Queue: Nic Hollingum <hollingum@google.com>
Cr-Commit-Position: refs/heads/master@{#633466}

Comments

[IntersectionObserver] Run algorithm in a post-lifecycle step
This is the first of two patches to change the timing of the
IntersectionObserver algorithm. Currently, the algorithm is run
during lifecycle updates, after paint. All notifications are queued
up to be delivered later; PostTask is used to schedule the delivery.
The main problem with this is that blink-internal consumers of
IntersectionObserver probably don't want their notifications to be
delayed, with the timing of delivery dependent on what's in the
task queue. It makes more sense for blink-internal consumers to get
their notifications synchronously; if they want to postpone some
until later, they can always PostTask from the notification handler.
Javascript IntersectionObservers will continue to schedule delivery
of notifications via PostTask.
This CL moves the IntersectionObserver algorithm to run outside of
the lifecycle proper. Instead, it runs in a post-lifecycle step.
This is necessary because when blink-internal IntersectionObserver
customers begin receiving synchronous notifications, they may mutate
document state in a way that shouldn't happen in the middle of a
lifecycle update.
Change-Id: I3fbcb97831776eee11564b36f1cfa933f5dfc712
Reviewed-on: https://chromium-review.googlesource.com/c/1468807
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Reviewed-by: Stefan Zager <szager@chromium.org>
Reviewed-by: Aleks Totic <atotic@chromium.org>
Commit-Queue: Stefan Zager <szager@chromium.org>
Cr-Commit-Position: refs/heads/master@{#633462}

Comments

Move ui_base_features into separate component
ui_base_features is currently part of ui/base:base. Despite the name,
ui/base:base is not the bottom layer in ui/, as it depends on certain
components such as ui/events:events.
In order to use ui_base_features to modify behavior in ui/events:events
we'll factor out ui_base_features into it's own component (it has to
be a component as it is comprised mainly of global variables).
Bug: 933396
Change-Id: I9c4d869001f70135af8fa2e3f6fc12c9ddd06223
Reviewed-on: https://chromium-review.googlesource.com/c/1478033
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Daniel Libby <dlibby@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#633458}

Changed files

ui/base/BUILD.gn

ui/base/ui_base_features.h

Fix directory listing not working for extension background pages with network service.

Comments

Revert "Add RenderFrameHost as parameter to WebContentsDelegate::HandleContextMenu"
This reverts commit 5705b913a577759d16b3eca7d5b0e7b5c79421f6.
Reason for revert: Suspect this caused a failure in content_unittests on Android CFI: https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Android%20CFI/4518
Original change's description:
> Add RenderFrameHost as parameter to WebContentsDelegate::HandleContextMenu
>
> To be able to do anything more complicated than block all context
> menu handling in HandleContextMenu you need the associated WebContents
> object. Current implementation that do something more currently handles
> that by either being a WebContentsObserver or keeping the WebContents
> object some other way.
>
> After WebContents checks WebContentsDelegate::HandleContextMenu the
> next delegate to get a chance is WebContentsViewDelegate::ShowContextMenu
> which takes a RenderFrameHost as additional parameter. This is all
> you need to get the WebContents object and other related information.
>
> So, to simplify writing WebContentsDelegate:s and override the
> context menu handling by actually showing something, include
> RenderFrameHost also in the HandleContextMenu call.
>
> I selected RenderFrameHost instead of WebContents that many
> other delegate methods use because it matches ShowContextMenu
> signature and there are already other delegate methods that
> also uses RenderFrameHost instead.
>
> WebContentsDelegate is a very popular interface, so this
> modifies a lot of files in different components but the
> changes are mechanical.
>
> Change-Id: I612202730f9a3badd38062e8284f1d50979e9377
> Bug: 932520
> Reviewed-on: https://chromium-review.googlesource.com/c/1472696
> Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
> Reviewed-by: Jochen Eisinger <jochen@chromium.org>
> Commit-Queue: Joel Klinghed <the_jk@opera.com>
> Cr-Commit-Position: refs/heads/master@{#633300}
TBR=ellyjones@chromium.org,the_jk@opera.com,jochen@chromium.org
Change-Id: I2c23108bebf04fb9248ad799f6e8e3917a93536b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 932520
Reviewed-on: https://chromium-review.googlesource.com/c/1478184
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Dirk Pranke <dpranke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#633454}

Comments

Feature-Policy: Opener policies
This CL introduces the "inherited opener feature policies". This
includes the logic to propagate feature policy states from a browsing
context to the auxiliary browsing contexts.
As the first step (and hidden behind flag) all the feature policies
will be inherited by the auxiliary browsing context. The only exception
is when the original context is sandboxed but allows popups to escape
sandbox.
The inheritance model will be fine tuned in further work. Firstly, not
all features might follow this "sandbox-like" inheritance model. Also
possibly through introducing a new Feature Policy (that replicates
'allow-popups-to-escape-sandbox') and special casing "rel='noopener'"
there will be exit doors for the open contexts to *not* inherit the
policies.
These issues are currently publicly being tracked here:
https://github.com/WICG/webappsec-feature-policy/issues/264https://github.com/WICG/webappsec-feature-policy/issues/252https://github.com/WICG/webappsec-feature-policy/pull/259
Bug: 774620
Change-Id: Ic0b5ab8155c2e5d786bc51d3f9c3a601f7e4d8e9
Reviewed-on: https://chromium-review.googlesource.com/c/1384992
Reviewed-by: Ehsan Karamad <ekaramad@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Ian Clelland <iclelland@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Ehsan Karamad <ekaramad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#633452}