Navigation type for SessionRestore and TabRestore is currently categorized as back_forward, and we could not tell if this was real history navigation or not internally.
This CL introduces a new WebFrameLoadType and NavigationType internally.
I preserved all the exposed behavior.
Bug: 1489567
Change-Id: I78fdca76c53b6a4323856090911b9e1539d03ba0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4903570
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Fergal Daly <fergal@chromium.org>
Reviewed-by: David Roger <droger@chromium.org>
Commit-Queue: Yuzu Saijo <yuzus@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1225315}
When creating a main frame for LocalMainFrame swap, we use the fenced
frame state on WebView to check if this is a main frame for a non top
level page. This misses other cases like GuestView. Fix this by tracking
this state explicitly on RenderFrameImpl using the params passed by the
browser.
Also disable compositor reuse when portals is enabled. Whether a frame
is embedded or not is baked into its compositor on creation. This means
this state can't be changed if we navigate a frame without changing its
compositor. This is an existing bug when the portal is activated. It's
now also triggering a CHECK if the portal has a same-SiteInstance
navigation after activation. Since portals is in the process of being
deprecated, avoid the optimization when the feature flag is enabled
instead of a proper fix.
R=rakina@chromium.org
Bug: 1464791
Change-Id: I9060e7d14232040f5d978dfc20b4b4a62bd77034
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5028114
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Auto-Submit: Khushal Sagar <khushalsagar@chromium.org>
Commit-Queue: Khushal Sagar <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1225230}
Currently for a LocalFrame swap, we steal the compositor from the
previous widget before the previous Document is torn down. This is
problematic because the script handlers invoked during old Document
teardown can trigger layout which can trigger forwarding state to the
compositor.
Avoid this issue by moving widget initialization for the new RenderFrame
after the previous Document has been torn down.
Bug: 1464791
Change-Id: Ie5ff91f97cebc926e9fa71f8a312ab92acb14d15
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5017755
Auto-Submit: Khushal Sagar <khushalsagar@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1224032}
When the page receives a HTTP response while it is in BFCache,
MojoURLLoaderClient::BodyBuffer drains the body mojo data pipe to its
buffer. And if the buffered data size exceeds the limit
`max_buffered_bytes_per_process`, the page will be evicted from the
BFCache. This logic was originally introduced by
https://crrev.com/c/2513314 and https://crrev.com/c/2539215.
Currently this logic doesn't work when BackgroundResourceFetch feature
is enabled, because EvictFromBackForwardCacheOnBackground() and
DidBufferLoadWhileInBackForwardCacheOnBackground() of
BackgroundURLLoader::Context is not implemented yet. So this CL
implement these methods and add tests in
BackForwardCacheNetworkLimitBrowserTest.
This cl introduces `update_process_wide_count` argument in
BackForwardCacheLoaderHelper::DidBufferLoadWhileInBackForwardCache()
methods. This argument is needed because BackgroundURLLoader need to
update the BackForwardCacheBufferLimitTracker.total_bytes_buffered_ in
the background thread, and update
LocalDOMWindow.total_bytes_buffered_while_in_back_forward_cache_ in the
main thread.
This CL also changes CreateResourceLoadInfoNotifierWrapper() method
of RenderFrameImpl to pass a kNetworking type task runner to the
constructor of ResourceLoadInfoNotifierWrapper. Without this,
ResourceLoadInfoNotifierWrapper may send an IPC to the browser process
even when the page is in the BFCache which will be recorded as
"BackForwardCache.UnexpectedRendererToBrowserMessage.InterfaceName" by
BackForwardCacheMessageFilter::WillDispatch, and EXPECT_THAT() in the
BackForwardCacheBrowserTest's destructor fails.
BackForwardCacheNetworkLimitBrowserTests are already flaky even without
this cl, so setting `Validate-Test-Flakiness: Skip`.
Bug: 1379780
Validate-Test-Flakiness: skip
Change-Id: Id13d11f0998c399ba5bf0991d1b5e7da865afca8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4996492
Reviewed-by: Yoshisato Yanagisawa <yyanagisawa@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1221917}
This CL aims to change the way ColorProvider objects are stored and
accessed in Blink. Currently, ColorProvider instances exist in
Blink::WebThemeEngine which exists per renderer process. This can cause
unexpected behavior when multiple WebContents instances share a single
renderer.
This CL stores ColorProvider objects in blink::Page, which is
associated with each WebContents instance. This ensures that Blink uses
the correct ColorProvider for each WebContents, and does not rely on
the global NativeTheme web instance.
This is a step towards deprecating the use of NativeTheme as a color
source and moving towards having all color access routed through
ColorProvider instances (regardless if the color is a "native" or
"browser" color).
This refactor will also enable us support a block list for the
PageColors feature, which will allow users override forced colors
state via a browser setting.
This CL adds the ColorProviderColors mojo type map to allow
sharing of the type between Blink and content and avoid needless
marshaling back and forth between types.
ColorProviderColors are propagated to the renderer's Page class in
the following cases:
1. When the RenderView is first created.
2. When the ColorProvider associated with the WebContents changes.
Bug: 1430181
Change-Id: I8003d93224b21785771d19b45826b1c4fc108843
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4898493
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Sam Davis Omekara <samomekarajr@microsoft.com>
Reviewed-by: Alison Maher <almaher@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1221134}
NavigationActivation is a new object (exposed as
`navigation.activation`). It is updated when a new Document is
"activated": initial Document creation, restore from bfcache, or
(in a future CL) prerender activation. It has three pieces of state:
* `activation.entry`: The current NavigationHistoryEntry at the time
of activation.
* `activation.from`: The current NavigationHistoryEntry immediately
before activation (i.e., the entry we came from). This will be
null if the navigation was cross-origin, or if the previous entry
was not in the same-origin contiguous region of the back/forward
list that is available in `navigation.entries()`.
* `activation.navigationType`: The navigationType ('push', 'replace',
'reload', or 'traverse') of the navigation that activated the
current Document.
Note that `entry` or `from` may be a NavigationHistoryEntry that is
no longer present in `navigation.entries()` (e.g., when doing a
replace navigation, `activation.from` will be the replaced entry).
In that case, the entry will remain visible, but because it is
a "disposed" entry, its index will be -1 and attempting to
`navigation.traverseTo()` its key will be rejected.
Initial discussion: https://github.com/whatwg/html/issues/9760
Draft spec PR: https://github.com/whatwg/html/pull/9856
I2p: https://groups.google.com/a/chromium.org/g/blink-dev/c/EfqxeH3Iwh4
Bug: 1492932
Change-Id: I2e090a8366906e4cb6778893ad9ffdca18d6ec37
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4990011
Reviewed-by: Domenic Denicola <domenic@chromium.org>
Commit-Queue: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1220983}
Currently BackgroundResourceFetch feature breaks the test
ContentSettingsAgentImplBrowserTest.ContentSettingsAllowScriptsWithSrc.
There are two reasons:
1: NotImplementedURLLoaderFactory is used for loading a resource from
the background thread because RenderFrameImpl::
LoadHTMLStringForTesting() initializes `pending_loader_factories_`
with a NotImplementedURLLoaderFactory. And NOTREACHED() check in
NotImplementedURLLoaderFactory::CreateLoaderAndStart() fails.
2: ContentSettingsAgentImplBrowserTest::OnCodeCacheHostRequest() is
called twice for the main thread and for the background thread.
But this method is designed to be called only once.
To fix these problems, this CL does the followings:
1: Change RenderFrameImpl::LoadHTMLStringForTesting() to initialize
`pending_loader_factories_` with
`url_loader_factory_override_for_test_` when it was set.
2: Change ContentSettingsAgentImplBrowserTest::OnCodeCacheHostRequest()
support being called multiple times.
Bug: 1379780
Change-Id: I5e946b2229b0b51729eeb4611332bb65ad0614f6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5007393
Reviewed-by: Martin Šrámek <msramek@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1220737}
This is a slightly different approach as taken in the past.
- The GinJavaBridge needs to be an associated interface so that the
AddNamedObject doesn't race with the navigation messages.
- The serialization is kept the same (no onion souping yet), all
serialization still occurs in content/renderer/java
- The content.mojom.GinJavaBridge interfaces are similar to the
blink.mojom.RemoteObject interfaces in the hopes that once this
approach proves correct and we have removed the legacy IPC we
can then proceed to change the serialization (and hosting where
the objects on the renderer side are bound but keeping the
content/browser/android/java implementation) and as well remove
the java based implementation that doesn't support associated
interfaces.
This interface is disabled by default and is toggled via the
GinJavaBridgeMojo feature flag.
Bug: 794320
Change-Id: Ifb0ad0b71ccb69f7149bbb772eee925adccb2050
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4968451
Reviewed-by: Richard (Torne) Coles <torne@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1220543}
This CL introduce BackgroundResourceFetch feature. When this feature is
enabled, the resource loading IPC URLLoaderFactory::CreateLoaderAndStart
will be triggered from the background thread by a new class
BackgroundURLLoader. This BackgroundURLLoader is created from a
BackgroundResourceFetchAssets which is attached to the frame.
See the design doc [1] for more details.
[1] https://docs.google.com/document/d/11cEc3KFpM7NwMMY9OkIUkIg5vGisNTXvzLZMgwBM-BM/edit?usp=sharing
Fuchsia-Binary-Size: Size increase is unavoidable.
Bug: 1379780
Change-Id: I7416ff112c46924181ea7f2739144b9e304981a0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4055197
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1215260}
# Context #
- `fetchLater()` is a flag-guarded new JS API.
- `FetchLaterLoaderFactory` is introduced as a fetchLater-specific
version of URLLoaderFactory to proxy Renderer->Browser IPC, while
Browser->Network IPC still uses URLLoaderFactory (not relevant to
this CL).
- Explainer: https://github.com/WICG/pending-beacon/blob/main/docs/fetch-later-api.md
- Design Doc: https://docs.google.com/document/d/1U8XSnICPY3j-fjzG35UVm6zjwL6LvX6ETU3T8WrzLyQ/edit
# Before this CL #
https://crrev.com/c/4907851 tries to allow binding
AssociatedRemote<FetchLaterLoaderFactory> from renderer via
`Frame::GetRemoteNavigationAssociatedInterfaces()` (See usage in [1]).
However, not every types of frame can bind it: browser-side impl of
FetchLaterLoaderFactory requires RFHI to have access to a copy of
`subresource_proxying_factory_bundle`, which is ONLY available after
navigation, i.e. RFHI for child frame or noopener window has no
access to it, as renderer just clones the other URLLoaderFactory
interfaces from parent/opener frames without passing
`subresource_proxying_factory_bundle` to RFHI.
# After this CL #
- RFHI passes pending_associated_remote<FetchLaterLoaderFactory> to
RenderFrameImpl via `NavigationClient::CommitNavigation()`.
- Stores mojo::AssociatedRemote<FetchLaterLoaderFactory> in
ChildURLLoaderFactoryBundle, so that it can be initialized/updated/
cloned along with other subresource URLLoaderFactory at the same
time.
- Surfaces `blink::ChildURLLoaderFactoryBundle` to
`blink::LocalFrameClient` via
`WebLocalFrameClient::GetLoaderFactoryBundle()`, so that it can be
used in FetchManager.
[1]: https://chromium-review.googlesource.com/c/chromium/src/+/4892556/21/third_party/blink/renderer/core/fetch/fetch_manager.cc#1586
Bug: 1465781
Change-Id: Idfa6c33cc19faadefe8ad2cd14b3b6df42e1a08d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4936910
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Ming-Ying Chung <mych@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1211297}
This CL introduces all of the plumbing for the an upcoming refactor
without hooking up the business logic on either end. This will allow for
simpler reviews of the business logic and associated tests.
This CL introduces a new mojom RendererContentSettings which is a member
of CommitNavigationParams. This mojom will contain pre-computed content
settings from the browser process on a per document basis.
The default values for this mojom come from the current implementation
of ContentSettingsAgentImpl and callsites. For example, the only
callsite to AllowPopupsAndRedirects sets a default value inline:
```
settings_client->AllowPopupsAndRedirects(false /* default_value*/)
```
Low-Coverage-Reason: Tests added in a subsequent CL.
Bug: 1485360
Change-Id: Ib7f0aca4164ed10823c80aa77ae032fb9dd515bd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4925109
Reviewed-by: Avi Drissman <avi@chromium.org>
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1208547}
Currently a WebURLRequestExtraData is passed to URLLoader just for
passing the top frame origin to variations::VariationsURLLoaderThrottle
which sets `X-Client-Data` HTTP request header for Field Trials
Variations. RenderFrameImpl::WillSendRequestInternal() is setting the
top frame origin to the WebURLRequestExtraData.
This CL changes it to directly pass `top_frame_origin` to URLLoader. The
`top_frame_origin` can be retrieved from FetchContext by calling
GetTopFrameOrigin() method.
This CL introduces a behavior change of subresource fetching from
dedicated workers. Currently if a web worker on a Google domain would do
a fetch, it would be treated as non-first-party. But after this change,
the fetch will be treated as first-party.
Bug: 1379780
Change-Id: I3e3cdfbde953ea7caff121c2bdb6a8d22834c901
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4886083
Reviewed-by: Yoshisato Yanagisawa <yyanagisawa@chromium.org>
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Caitlin Fischer <caitlinfischer@google.com>
Cr-Commit-Position: refs/heads/main@{#1206209}
This change is not intended to change any behavior. This is a
mediumweight rewrite applied primarily to renderer code, promoting a
bunch of `T*` into `raw_ptr<T>` (or `T&` to `raw_ref<T>`).
MiraclePtr is not yet generally enabled in the renderer process,
so this should only affect rewritten members by turning them into
no-op `raw_ptr` (thought to have negligible overhead).
Given the scope of the rewrite and the security benefits, we feel that
the binary size increase is unavoidable.
AX-Relnotes: n/a.
Binary-Size: Size increase is unavoidable (see above).
Bug: 1444624
Change-Id: I1cda6fe446b1a8552cb3c98c1afeae0f15218619
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4904523
Owners-Override: Keishi Hattori <keishi@chromium.org>
Commit-Queue: Kalvin Lee <kdlee@chromium.org>
Reviewed-by: Keishi Hattori <keishi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1203810}
We need to set the origin_to_commit for data: URLs as part of the
transition to removing source SiteInstance from RenderFrameProxyHost.
Because data: URLs have opaque origins, we cannot identify which data:
URL is the source SiteInstance if there are multiple data: SiteInstances
in a group. By using the origin_to_commit, we can compare origin nonces
to make sure we use the correct data: URL SiteInstance as the source
SiteInstance.
We want the browser and renderer side nonces to match. Without this change, the
renderer calculates its own opaque origin, which will differ from the origin
used on the browser side to create a data: SiteInstance. If the browser and
renderer side origins don't match, we can't use it to identify a data: URL
SiteInstance.
We do not include LoadDataWithBaseUrl cases with a base URL because we don't
need SiteInstanceGroup in those cases. The base URL will be used to determine
the SiteInstance. If the base URL is empty, then the URL is treated like a
regular data: URL.
Bug: 1447896, 1291351
Test: Added NavigationControllerBrowserTest.DataURLHasCommittedOrigin
Change-Id: Ifaf3acfa15d16aff78b8643f88fcc69c619b5c5e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4824705
Commit-Queue: Sharon Yang <yangsharon@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1199187}
There are two headers to declare features in content.
- the public one: `content/public/common/content_features.h`
- the private one: `content/common/features.h`.
Unfortunately, most are declared in the public one, despite being used
privately exclusively. This violate the `content/public/` rules. This
patches provides a fix.
Parts of this patch was made programmatically using this script:
https://paste.googleplex.com/6699322946093056, with the following
output: https://paste.googleplex.com/5591288895242240
This patch:
1. Update `docs/how_to_add_your_feature_flag.md` to incentive
developers to the non public versions.
2. Move ~70 features back into the private version.
3. Programmatically update the includes to include the correct
#include header(s).
4. For consistency and minimizing the amount of files modified,
the two headers to use the `features::` namespace.
AX-Relnotes: n/a.
Change-Id: Id9126a95dfbc533d4778b188b659b5acc9b3d9e3
Bug: None
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4836057
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1194718}
There are 3 crash bugs that might be related, where we see:
- A BeginNavigation message from the renderer, where the initiator
origin doesn't match the process lock (see crbug.com/1474261#c2)
- A DidCommitProvisionalLoad message from the renderer for an
about:blank page, where the committed origin doesn't match the
process lock (see crbug.com/1470837#c2)
- A crash in RenderFrameImpl::BeginNavigation() which might be caused
by a recently added debugging CHECK for origin equality of
a synchronously committed about:blank document and its parent
(see crbug.com/1476614)
This CL adds some debugging to figure out the state of the world when
the crash happens, and also fixes some errors in previous CLs.
Bug: 1474261, 1470837, 1476614
Change-Id: I5419ef609fed2036c3c6cea7c4629d89ae47c143
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4829483
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1192730}
Currently when blink fetches a request, WillSendRequest() methods [1]
create URLLoaderThrottles, and set them to WebURLRequestExtraData.
And URLLoader::Context::Start() takes them from the
WebURLRequestExtraData.
This CL changes it to create URLLoaderThrottles in
ResourceFetcher::LoaderFactory::CreateURLLoader() method [2]. And pass
them directly to the constructor of URLLoader.
This should not introduce any behavior change. This CL is a preparation
for the off the main thread resource loading project. We want to keep a
URLLoaderThrottleProvide in the background thread instead of passing
URLLoaderThrottles from the main thread to the background thread every
time for each request. It is because passing a URLLoaderThrottle to
another thread may require IPC call in the browser thread
(eg: safe_browsing::MojoSafeBrowsingImpl::Clone()) which is not good for
the performance.
[1] RenderFrameImpl::WillSendRequest() for frames,
DedicatedOrSharedWorkerFetchContextImpl::WillSendRequest() for
dedicated workers and shared workers,
WebServiceWorkerFetchContextImpl::WillSendRequest() for service
workers.
[2] LoaderFactoryForFrame::CreateURLLoader() for frames,
LoaderFactoryForWorker::CreateURLLoader() for workers,
Bug: 1379780
Change-Id: I7979aabd09f618748f7abfbc1729544e0add5f97
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4806662
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1192020}
This is a reland of commit e63b2d3673
** Reason for revert: new CHECK() caused AccessibilityIpcErrorBrowserTest.ResetBrowserAccessibilityManager to fail on many bots, because the test used set_no_create_browser_accessibility_manager_for_testing(true).
The test is only enabled on builds without DCHECKs enabled, thus failed in CQ.
Sample failure on linux-bfcache-rel:
https://ci.chromium.org/ui/p/chromium/builders/ci/linux-bfcache-rel/50476/test-results?sortby=&groupby=
The same new CHECK() was also sometimes triggered when SendAccessibilityEventsToManager() was called by UpdateAXTreeData().
This was filed as in crbug.com/1477218.
** How addressed:
Removed new CHECK added in RenderFrameHostImpl::SendAccessibilityEventsToManager() which tries to ensure that kNavtiveAPIs was clear when there was no BrowserAccessibilityManager.
Original change's description:
> Toss stale a11y serializations that were sent by a renderer while the
> browser was changing AXMode
>
> When the accessibility mode changes, the page is reset and then the
> entire page is re-sent from the root down (because the entire page is
> marked dirty).
>
> Any in flight serializations from right before the mode change was
> received are obsolete and should be thrown on the floor.
>
> Without this change, the obsolete serialization could be applied to a
> brand new AXTree that was recently created because of the mode change,
> and which doesn't have the nodes being referred to in the serialization,
> causing mysterious fatal errors in AXTree in the form, "Node X will not
> be in the tree and is not the new root".
>
> Bug: 1471373
> Change-Id: Ib15fec5355aee5fd515675a56034d5fb8e786c12
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4814368
> Auto-Submit: Aaron Leventhal <aleventhal@chromium.org>
> Reviewed-by: David Tseng <dtseng@chromium.org>
> Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
> Reviewed-by: John Abd-El-Malek <jam@chromium.org>
> Reviewed-by: Robert Sesek <rsesek@chromium.org>
> Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1189717}
Bug: 1471373, 1477218
Cq-Include-Trybots: luci.chromium.try:linux-bfcache-rel
Change-Id: I89971b6210045428c935ad54ff82f1e5f56b1f33
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4825983
Reviewed-by: David Tseng <dtseng@chromium.org>
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1190158}
This reverts commit e63b2d3673.
Reason for revert: This CL may be causing AccessibilityIpcErrorBrowserTest.ResetBrowserAccessibilityManager to fail on many bots.
Original change's description:
> Toss stale a11y serializations that were sent by a renderer while the
> browser was changing AXMode
>
> When the accessibility mode changes, the page is reset and then the
> entire page is re-sent from the root down (because the entire page is
> marked dirty).
>
> Any in flight serializations from right before the mode change was
> received are obsolete and should be thrown on the floor.
>
> Without this change, the obsolete serialization could be applied to a
> brand new AXTree that was recently created because of the mode change,
> and which doesn't have the nodes being referred to in the serialization,
> causing mysterious fatal errors in AXTree in the form, "Node X will not
> be in the tree and is not the new root".
>
> Bug: 1471373
> Change-Id: Ib15fec5355aee5fd515675a56034d5fb8e786c12
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4814368
> Auto-Submit: Aaron Leventhal <aleventhal@chromium.org>
> Reviewed-by: David Tseng <dtseng@chromium.org>
> Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
> Reviewed-by: John Abd-El-Malek <jam@chromium.org>
> Reviewed-by: Robert Sesek <rsesek@chromium.org>
> Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1189717}
Bug: 1471373
Change-Id: I48b4b6f0a6814b554a94d8c643e84c2299a239bd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4824746
Commit-Queue: Ian Wells <iwells@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Owners-Override: Ian Wells <iwells@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#1189826}
browser was changing AXMode
When the accessibility mode changes, the page is reset and then the
entire page is re-sent from the root down (because the entire page is
marked dirty).
Any in flight serializations from right before the mode change was
received are obsolete and should be thrown on the floor.
Without this change, the obsolete serialization could be applied to a
brand new AXTree that was recently created because of the mode change,
and which doesn't have the nodes being referred to in the serialization,
causing mysterious fatal errors in AXTree in the form, "Node X will not
be in the tree and is not the new root".
Bug: 1471373
Change-Id: Ib15fec5355aee5fd515675a56034d5fb8e786c12
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4814368
Auto-Submit: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: David Tseng <dtseng@chromium.org>
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1189717}
Enabling RenderDocument causes same-origin navigations to swap to a new
RenderFrameHost. However, when a RenderFrameHost is changed, the browser
dispatches synthetic mouse events to ensure the renderer knows where the
mouse cursor is. In web tests using the event_sender API, events are
injected into Blink synchronously so the browser-generated synthetic
events may be processed after test events which can affect test output.
This CL changes the web test runner to ensure all synthetic events have
been flushed and processed before the test is started. It does this by
blocking parsing in a web test until input has been flushed, the order
of events from the perspective of WebTestControlHost:
* Initial-state/Test Finished: Set a `next_nav_is_new_test` bit.
* READY_TO_COMMIT: If `next_nav_is_new_test` - call
BlockTestUntilStart in the renderer which blocks parsing in the
current DocumentLoader, before it starts loading the new document.
* <During CommitPending>: Post a task to generate the synthetic
events.
* DID_FINISH_NAVIGATION: If `next_nav_is_new_test` - clear the bit and
post a task to:
* Flush input - this waits until all input has been IPC'd to the
renderer and ACK'd. Note: input may still be queued in
renderer-side compositor or main thread queues.
* Calls StartTest on the renderer.
* StartTest (in renderer)
* Flushes the compositor queue to ensure all its input has been
processed (this may result in queueing input on the main thread).
* Flushes the main thread event queue.
* Unblocks the parser.
Bug: 1416496
Change-Id: I2ac0c3745e74a0a01055d5e7a474036096b8ec6f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4727485
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Joe Mason <joenotcharles@google.com>
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1188325}
Subresource request blocking logic was introduced [1] to block
subresource requests from the browser process by calling BlockRequests()
IPC. InterstitialPageImpl used this logic. But it was removed [2] after
Committed Interstitials [3] was introduced.
Currently RenderFrameHostImpl::CreateNewWindow() calls BlockRequests()
to block subresource requests when `waiting_for_init_` is true. And
RenderFrameHostImpl::Init() is calling ResumeBlockedRequests() to resume
them. But it sounds useless because navigation is also blocked until
Init() is called, and no subresource requests should be fetched. So this
CL removes this logic, and all subresource request blocking related
logic.
[1] https://crrev.com/c/1164542
[2] https://crrev.com/c/2146137
[3] https://crbug.com/755632
Bug: 581037
Change-Id: Iecab896362b54fa2b5c3fcb1eac2cd3575e29f7e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3954952
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1187690}
In crbug.com/1470837 we saw crashes for subframe about:blank
navigations that use the DidCommitProvisionalLoad path (not
DidCommitNavigation path), which hints that it might be related
to synchronous about:blank commits. This CL adds crash keys and
CHECKs to confirm.
Bug: 1470837
Change-Id: I55f2adadc4d36e6647cce2a111cba6c13159a4d3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4764964
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1184384}
When we are committing the same RenderFrame as the previous document and
there's a pre-existing LCPP hint, and when there are no LCPP element
hints, we want to remove the existing hint. Hence this CL updates
SetLCPPHint() to clear the existing hint.
Bug: 1419756
Change-Id: Iae4735a19816ff47f74a05ef114e1c9157014ffd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4741252
Reviewed-by: Yoshisato Yanagisawa <yyanagisawa@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Minoru Chikamune <chikamune@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1178364}
Despite the fact that there is a ARCH_CPU_ARM64 macro, it turns out
there is no corresponding ARCH_CPU_ARM32 macro. Oops.
Bug: 1461901
Change-Id: I766f5f05d1de2f54b15f8159f77c9e3c29668ebe
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4698037
Reviewed-by: Richard Coles <torne@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1172023}
Stack trace collection is broken in the renderer sandbox on CrOS ARM64,
since it tries to use syscalls that are disallowed by the sandbox.
Stack trace collection is also (flakily) broken on Android ARM32, since:
- ARM32 does not use frame pointers
- so the unwinder must use unwind tables
- but due to random data corruption (in CPU or RAM), the unwind tables
sometimes contain bogus data
- which libunwind does not handle gracefully
Also enable the reporting code on Android, since it's a bit silly to
collect the stack traces but not do anything with them.
Bug: 1461901
Change-Id: I62175b1976c91f781e0a08fecae96ea6fe87319a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4681306
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1170622}
Why: current heuristic only considers is_ad_script_in_stack, which
doesn't cover the scenario where the initiator frame is an Ad frame
but there's no script at all (e.g. direct <a> click).
This change is believed to only impact RenderFrameImpl::OpenURL() / BeginNavigationInternal() / CreateNewWindow(), and we have tests to
cover each code path. For RemoteFrame::Navigate(), it's believed that
it can only be triggered via JS which should already check the
(initiator) context's ad status, but we include the new bit
nevertheless to be consistent.
Bug: 1464298
Change-Id: I679fc340fbe8bcca362e1f7d37cd9ddf2bbb4dee
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4679831
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Reviewed-by: Josh Karlin <jkarlin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1170612}
We recently added a DevTools issue for CORB/ORB errors. This
CL removes the console message. This enables a cleanup where
we eliminate the should_report_corb_blocking flag, which
is currently being passed from the network service to the
renderer in order to enable the message.
This CL looks complex, but it's mostly deletions.
Bug: 1463725
Change-Id: Ia1cb3e277173dd83be611ac4e8752ff90cd7c28e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4359633
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Nate Chapin <japhet@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Camille Lamy <clamy@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1169859}
These URLs will fail the FilterURL check. Instead, use about:blank
since this is what the actual document URL will be instead.
Bug: 1357515
Change-Id: I8abe4f32a16c7112673ae8e4e33b22521ea4c907
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4670267
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1169584}
In https://crrev.com/c/4479858, we introduced a new boolean that
constrains whether an execution context can be considered
crossOriginIsolated. It is computed by the browser, depending on whether
the COOP origin matches the actual origin. This boolean is computed and
sent to the renderer at window creation time, or at commit time for
subframes. It causes breakage such as b/288962508 (Google
only) because SharedArrayBuffer's constructor sometimes needs to be
enabled earlier than CommitNavigation, which causes SharedArrayBuffer to
be undefined even though crossOriginIsolated is true.
This CL instead puts the boolean inside the policy container and lets it
handles inheritance.
Bug: 1385827
Change-Id: I1330c30ad056d9f94ee7b7747eac68ae47b56acc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4666003
Commit-Queue: Jonathan Hao <phao@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Arthur Hemery <ahemery@chromium.org>
Reviewed-by: Yoav Weiss <yoavweiss@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1168653}
The previous fix relied on FilterURL behavior which may soon be
changing. Instead, detect the javascript: URL case in the
renderer process.
This is expected to cause no change in behavior, and relies on
the existing test coverage in
PopupWindowTest#testSingleWindowModeJsInjection.
Bug: 1083819
Change-Id: I1733d896064f4b193593ae9b47a02d28d9424284
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4675673
Reviewed-by: Richard Coles <torne@chromium.org>
Commit-Queue: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1168321}
This is a reland of commit 286d6c89c8
base::debug::StackTrace appears to be broken in the CrOS aarch64
renderer sandbox, so only collect renderer-side stack traces on
non-aarch64 platforms.
Original change's description:
> Add crash logging to debug a state desync between browser and renderer.
>
> The original race was addressed long ago by `UndoCommitNavigation()`
> and, later on, the proper fix using navigation queueing. Unfortunately,
> the crash count has recently increased by quite a bit with no obvious
> cause.
>
> While this CL does capture the stack trace in quite a few places,
> similar crash logging has been previously used without impacting
> performance too severely. Hopefully it will be possible to gather enough
> crash data so that this can be reverted shortly.
>
> Bug: 1425281
> Change-Id: I9aec3b4432d5c9290dfb80422b9ab7bafa9cfc92
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4630812
> Commit-Queue: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1161058}
Bug: 1425281
Cq-Include-Trybots: luci.chrome.try:lacros-arm64-generic-chrome-skylab
Fuchsia-Binary-Size: This is a temporary debugging CL.
Change-Id: If26321f5fdb8dbd940d729f8b47a3900465874df
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4637499
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1162565}
This reverts commit 286d6c89c8.
Reason for revert:
Speculative revert.
tast.lacros.Basic
tast.login.Chrome.lacros
tast.a11y.Smoke.lacros
are consistently failing on builder "chromium/ci/lacros-arm64-generic-rel-skylab"
See linked bug. Or #gardening slack thread: https://chromium.slack.com/archives/CGJ5WKRUH/p1687451406348529
It appears to be a crash. Nothing on the blamelist is particularly tempting.
BUG=1457163
Original change's description:
> Add crash logging to debug a state desync between browser and renderer.
>
> The original race was addressed long ago by `UndoCommitNavigation()`
> and, later on, the proper fix using navigation queueing. Unfortunately,
> the crash count has recently increased by quite a bit with no obvious
> cause.
>
> While this CL does capture the stack trace in quite a few places,
> similar crash logging has been previously used without impacting
> performance too severely. Hopefully it will be possible to gather enough
> crash data so that this can be reverted shortly.
>
> Bug: 1425281
> Change-Id: I9aec3b4432d5c9290dfb80422b9ab7bafa9cfc92
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4630812
> Commit-Queue: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1161058}
Bug: 1425281
Change-Id: Ic3a94db0ec6c4b4beba56c99e33f0dcafc686a1b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4637490
Commit-Queue: Mark Pearson <mpearson@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Mark Pearson <mpearson@chromium.org>
Auto-Submit: Mark Pearson <mpearson@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1161488}
The original race was addressed long ago by `UndoCommitNavigation()`
and, later on, the proper fix using navigation queueing. Unfortunately,
the crash count has recently increased by quite a bit with no obvious
cause.
While this CL does capture the stack trace in quite a few places,
similar crash logging has been previously used without impacting
performance too severely. Hopefully it will be possible to gather enough
crash data so that this can be reverted shortly.
Bug: 1425281
Change-Id: I9aec3b4432d5c9290dfb80422b9ab7bafa9cfc92
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4630812
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1161058}
