This is a reland of commit 964be52ca6
The reland fixes the Android ARM failures caused by small RAM size.
Original change's description:
> Reland "Skip GetFrameHostForNavigation if the creation of the RFH is deferred"
>
> This is a reland of commit 2879994fc3
>
> The reland fixes the test failures when running Andrdoid tests without
> BFCache. The spare renderer will be created regardless of the BFCache
> state.
>
> Original change's description:
> > Skip GetFrameHostForNavigation if the creation of the RFH is deferred
> >
> > The CL skips the whole GetFrameHostForNavigation function if the
> > creation of the speculative RFH can be deferred. Navigation traces
> > showed that calling GetFrameHostForNavigation itself can be
> > time-consuming even if the creation of the RFH is deferred.
> >
> > The design doc can be found at:
> > https://docs.google.com/document/d/1J0D5-qireiIngmyeiaMtHrKKRWbiYOtrCqxqeuNhhxE/edit?usp=sharing
> >
> > Bug: 332435024
> > Change-Id: Id6fb4d92ccbfc3e334c4d3e84583736aaf053e79
> > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6224174
> > Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
> > Commit-Queue: Jiacheng Guo <gjc@google.com>
> > Cr-Commit-Position: refs/heads/main@{#1419053}
>
> Bug: 332435024
> Change-Id: I85e5ab0fc81471bbc5ebb7563af1ec6ae7639da3
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6255360
> Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
> Commit-Queue: Jiacheng Guo <gjc@google.com>
> Cr-Commit-Position: refs/heads/main@{#1420226}
Bug: 332435024
Change-Id: Id4c7837c43c12baf2a0d22d4f0ebfafcb470de0e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6274684
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Jiacheng Guo <gjc@google.com>
Cr-Commit-Position: refs/heads/main@{#1420905}
This is a reland of commit 2879994fc3
The reland fixes the test failures when running Andrdoid tests without
BFCache. The spare renderer will be created regardless of the BFCache
state.
Original change's description:
> Skip GetFrameHostForNavigation if the creation of the RFH is deferred
>
> The CL skips the whole GetFrameHostForNavigation function if the
> creation of the speculative RFH can be deferred. Navigation traces
> showed that calling GetFrameHostForNavigation itself can be
> time-consuming even if the creation of the RFH is deferred.
>
> The design doc can be found at:
> https://docs.google.com/document/d/1J0D5-qireiIngmyeiaMtHrKKRWbiYOtrCqxqeuNhhxE/edit?usp=sharing
>
> Bug: 332435024
> Change-Id: Id6fb4d92ccbfc3e334c4d3e84583736aaf053e79
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6224174
> Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
> Commit-Queue: Jiacheng Guo <gjc@google.com>
> Cr-Commit-Position: refs/heads/main@{#1419053}
Bug: 332435024
Change-Id: I85e5ab0fc81471bbc5ebb7563af1ec6ae7639da3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6255360
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Jiacheng Guo <gjc@google.com>
Cr-Commit-Position: refs/heads/main@{#1420226}
When kHstsTopLevelNavigationsOnly is active we want to apply HSTS
upgrades to "real" top-level navigations only, not MPArch frames such as
Fenced Frames. This CL corrects the usage of IsMainFrameRequest() to
IsOutermostMainFrameRequest().
Bug: 40725781
Change-Id: Idaaedc61b4bb1ed5cd3b24f891f895335274b78b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6226288
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Steven Bingler <bingler@chromium.org>
Reviewed-by: mmenke <mmenke@chromium.org>
Reviewed-by: Chris Thompson <cthomp@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1416936}
Now that kProcessSharingWithDefaultSiteInstances has been removed, the
test util that checks the feature can be removed. This will also become
unnecessary once we replace the default SiteInstance with a default
SiteInstanceGroup
Test: Test cleanup
Bug: 356624048
Change-Id: Ib1f07a0c87e842d3cca8a6a463da7405de742bb1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6175358
Commit-Queue: Sharon Yang <yangsharon@chromium.org>
Owners-Override: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1406846}
This change adds a, default disabled, feature which when enabled will
only allow top-level navigations to be upgraded by HSTS.
This CL also refactors some tests that are broken by this change:
* Because websockets are considered sub-resource requests they'll never
be upgraded and so tests for this behavior only run with the feature
disabled.
* Other tests that aren't specifically testing for sub-resources are
changed to be main frame navigation requests.
Bug: 40725781
Change-Id: I072a06debbe0034802c601cd0620bc6e73bde3f3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5859646
Reviewed-by: mmenke <mmenke@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Steven Bingler <bingler@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1396041}
This CL introduces multiple SiteInstances per SiteInstanceGroup for
subframe data: URLs. This feature is behind the feature flag
kSiteInstanceGroupsForDataUrls, which is disabled by default, so there
is no behaviour change in this CL.
Subframe data: URLs will now have their own
SiteInstance that goes in the same SiteInstanceGroup as its initiator.
Currently, sandboxed data: subframes are excluded, as they require
computing a variation of the initiator SiteInstance, which is out of
scope for this CL and will be added in a followup.
Because the new data: subframe shares a SiteInstanceGroup with its
initiator, the number of processes remains the same as before.
Test: Added SiteInstanceGroup browsertests
Change-Id: If784b21ceccd440e35c0020053823ae287cf931d
Bug: 40269084
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4675093
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Elly FJ <ellyjones@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Sharon Yang <yangsharon@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1382080}
The main complexity of this CL is from tests that assume the
existence of only 1 spare, and making sure the task_manager can
track multiple spares.
So for browser tests that check if a spare is used in a navigation,
the idea is to keep a copy of all spares before the navigation, and
check that the taken renderer is contained in that collection.
An exception is browser tests that uses
SpareRenderProcessHostStartedObserver. Those tests still assumes
only 1 spare, as the observer will still only be notified when
the first spare is created.
In unit tests, it is generally safe to assume there can only be 1
spare, because the actual spare management functions are called by
the tests (e.g. The test calls WarmupSpare exactly once, so there
will be only one spare).
Bug: 364635886
Change-Id: Id9c7c7bd88740571b3f238ba6c7115195409a6b7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5889790
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Ahmed Fakhry <afakhry@chromium.org>
Commit-Queue: Patrick Monette <pmonette@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1366339}
There is code that wants to be notified when the spare renderer is
created and then used/deleted (Mostly the task manager, and also
some tests). This is currently achieved through the
RegisterSpareChangedCallback() function.
In a future world where there is potentially more than one spare
renderer, this approach doesn't work.
Instead, replace it with an observer interface that clearly
indicates when a spare is started, and when a spare either is
used or deleted.
With the callback approach, the callback was invoked immediately
upon registration if there was an existing spare. With the
observer approach, this is not done automatically and observers
must now call GetSpare(), which is now an official public method
for getting the spare renderer. This means the GetSpareForTesting
method is removed.
Bug: 364635886
Change-Id: Ida3afbc6c27318b6598d71e8657cdf824cff46b2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5868155
Commit-Queue: Patrick Monette <pmonette@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1359580}
Currently, the public interface (outside content/) for accessing¸
the spare RPH is through static methods of RenderProcessHost.
This CL splits SpareRenderProcessHostManager into a public interface
and a private implementation.
Inside content/, using SpareRenderProcessHostManagerImpl is
prefered.
No behavioral change, refactor only.
Bug: 364635886
Change-Id: I612de785dd709d5dff39ae37f01c15624dc00617
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5867079
Commit-Queue: Patrick Monette <pmonette@chromium.org>
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1359098}
This change is meant to improve readability by reducing the length
of the method names of a class with an already long name.
Bug: 364635886
Change-Id: Ie45c49a0ed47fc525050af7128df71cd2b280989
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5858280
Commit-Queue: Patrick Monette <pmonette@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1356827}
This test was flaky on Fuchsia and ChromeOS Ash. The theory is that we
need to wait longer for the VisualProperties update to come in. Waiting
for a lifecycle update will hopefully ensure that update has happened.
Bug: 361299696
Change-Id: I2479f5f8b7daab68f05e3c23ec0b477e6d63640d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5857258
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Brandon Maslen <brandm@microsoft.com>
Auto-Submit: Erik Anderson <Erik.Anderson@microsoft.com>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1355281}
There was a crash in the wild in RenderProcessHost and SiteInstanceGroup
DecrementNavigationStateKeepAliveCount. Fix that by checking if
ref counts are disabled before incrementing/decrementing the ref count.
Test: Added a regression test in NavigationBrowserTest
Bug: 348150830
Change-Id: Iefc032e60b4ae164f67ea4cae1712333da3e7484
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5841865
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1354245}
A series of tentative WPTs were written to test updates to our
framebusting interventions. Some of the tests written test non-standard
behavior, and have been resulting in failures when other browsers (who
have not implemented our framebusting interventions) try to run them.
There are also issues with some of the tests themselves when running in
headless mode, as they require giving user activation to a subframe in a
separate window the test opens, which is something headless mode doesn't
currently support. To fix both of these problems, this CL refactors the
problematic tests into browser tests.
Most of the WPTs are staying as is, since they test standard behavior
and don't have compatibility issues with headless mode.
The following tests are being refactored into browser tests:
* sandbox-top-navigation-cross-origin-escalate
* now FramebustingFromPrivilegeEscalationFails
* sandbox-top-navigation-child-cross-origin-delivered
* now FramebustingFromDeliveredFlagsFails
* sandbox-top-navigation-cross-site
* now FramebustingAfterCrossSiteNavigationFails
* sandbox-top-navigation-grandchild-sandboxed-escalate
* now FramebustingFromGrandchildPrivilegeEscalationFails
* sandbox-top-navigation-same-site-no-activation
* now FramebustingAfterSameSiteNavigationWithoutUserActivationFails
* sandbox-top-navigation-same-site
* now FramebustingAfterSameSiteNavigationSucceeds
The following tests have duplicates and are being removed altogether:
* sandbox-top-navigation-child-frame-both
* duplicate of iframe_sandbox_allow_top_navigation-3
* sandbox-top-navigation-child-frame
* duplicate of iframe_sandbox_allow_top_navigation-1
* sandbox-top-navigation-grandchild-unsandboxed
* duplicate of sandbox-top-navigation-grandchild-unsandboxed-cross-origin-parent
* sandbox-top-navigation-user-activation-no-sticky
* duplicate of iframe_sandbox_allow_top_navigation_by_user_activation_without_user_gesture
* sandbox-top-navigation-user-activation-sticky
* duplicate of
iframe_sandbox_allow_top_navigation_by_user_activation-manual
The following tests rely on manual behavior and, while not being
removed, are getting an equivalent browser test:
* iframe_sandbox_allow_top_navigation_by_user_activation_without_user_gesture
* now FramebustingWithAllowTopNavigationByUserActivation
* iframe_sandbox_allow_top_navigation_by_user_activation-manual
* also now FramebustingWithAllowTopNavigationByUserActivation
Bug: 347782854
Change-Id: I3b39a9d51db3dd725c8a88eac0bb464fa4753c04
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5813532
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Liam Brady <lbrady@google.com>
Cr-Commit-Position: refs/heads/main@{#1348945}
Previously same-origin navigations will keep the same LocalFrame,
and we track focused frames in the controller as LocalFrames. This
means the "focused" frame status will survive same-origin navigations.
With RenderDocument, we won't keep the same LocalFrame after
navigations, and will clear out the focused frames as the previous
LocalFrame gets swapped out/detached. This is causing regressions,
see also linked bug. This CL makes it so that we keep the previous
behavior by keeping track of whether the previous LocalFrame is
the focused frames, then marking the new LocalFrame as focused.
Fixed: 360705823
Change-Id: I9fcf2f936775fd17b63f381919b05805edeff3bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5802555
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1348396}
I've not been able to locally repro the flakiness seen with this test,
even with 1000 runs on both debug and release Linux builds. The failing
test logs indicate that the correct viewport size has not reached the
renderer. This is a speculative change to clear the "ack pending" flag
when we clear the visual properties with the expectation that it should
more immediately push down the correct size vs. waiting for a later
call to trigger the update.
Bug: 361299696
Change-Id: Iad6d236380094e03ddccda4bc4c4c2f4f1e74a29
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5807530
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Erik Anderson <Erik.Anderson@microsoft.com>
Auto-Submit: Erik Anderson <Erik.Anderson@microsoft.com>
Reviewed-by: Brandon Maslen <brandm@microsoft.com>
Commit-Queue: Brandon Maslen <brandm@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1346896}
We currently miss plumbing this bit to the renderer since it's set on
the navigation request after the commit message is already sent. Fix
that timing and update the browser test to include the complete flow.
Bug: 331671779
Change-Id: I857dbe903e746945e5e5c06146bc0c83c8ade0f5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5804907
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Auto-Submit: Khushal Sagar <khushalsagar@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: William Liu <liuwilliam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1345671}
Prior to this change, a race condition existed when a WebViewImpl
transitions from being a remote frame to a local frame. The updated
visual properties were not sent based on the timing of when different
navigations completed.
This race condition was commonly seen in Microsoft Edge with an internal
site which kicked off a top-level nav to another origin and immediately
afterward navigated an iframe to a page of the same origin.
The included test emulates this situation. Prior to this change, the
test consistently fails with the renderer having a 0x0-sized viewport.
Bug: 352093463
Change-Id: Ia2bab87a040395a534fda21069250b5fd08df6e1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5785294
Reviewed-by: Jan Keitel <jkeitel@google.com>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Auto-Submit: Erik Anderson <Erik.Anderson@microsoft.com>
Commit-Queue: Jan Keitel <jkeitel@google.com>
Cr-Commit-Position: refs/heads/main@{#1341485}
HttpRequestHeaders::GetHeader has a new overload
which returns an optional instead of using an out-
parameter. I'm migrating callers and will eventually
delete the old version of the method.
This CL was uploaded by git cl split.
R=boliu@chromium.org
Bug: 355451174
Change-Id: I0b0027bf9d418bb274b0f2da3fdda62a039b9731
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5748517
Reviewed-by: Bo Liu <boliu@chromium.org>
Auto-Submit: Chris Fredrickson <cfredric@chromium.org>
Commit-Queue: Bo Liu <boliu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1334969}
This is a reland of commit a0507e59a8
PS2 fixes the failing CreationNotDeferredWithoutURLLoader test.
Original change's description:
> Add WillCommitWithoutUrlLoader handling to RendererCancellationThrottle
>
> Currently it only handles WillProcessResponse, so it didn't capture
> no-URLLoader navigations like about:blank. This CL makes it so that
> it captures both navigations with and without URLLoader.
>
> Bug: 352352911
> Change-Id: I0a75a4f80c04d7ec540ed74c63a07098797293c9
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5741319
> Reviewed-by: Mingyu Lei <leimy@chromium.org>
> Commit-Queue: Mingyu Lei <leimy@chromium.org>
> Auto-Submit: Rakina Zata Amni <rakina@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1333343}
Bug: 352352911
Change-Id: I9dc788aff3b8b025a930fdd73e42606efdbde500
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5740921
Reviewed-by: Mingyu Lei <leimy@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1333443}
This is a reland of commit Iebce93f58e73749780bc32389266f0f70b9b3403.
The CL is not the cause of the CI failure and incorrectly reverted.
Original change's description:
> The CL adds a UMA to record whether the speculative RFH creation is
> deferred and whether a spare render process is created.
>
> Bug: 332435024
> Change-Id: Iebce93f58e73749780bc32389266f0f70b9b3403
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5657751
> Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
> Commit-Queue: Jiacheng Guo <gjc@google.com>
> Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1320224}
Cq-Include-Trybots: luci.chromium.try:chromeos-amd64-generic-asan-rel
Bug: 332435024
Change-Id: I91b92244ff8cd891337e2841dbec55c1cee1d36a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5665335
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Jiacheng Guo <gjc@google.com>
Cr-Commit-Position: refs/heads/main@{#1320779}
This reverts commit 18fc97e19f.
Reason for revert: LUCI bisect as a reason for chromeos-amd64-generic-asan-rel failure, which closed the tree.
Original change's description:
> Add UMA to record the deferred speculative RFHs
>
> The CL adds a UMA to record whether the speculative RFH creation is
> deferred and whether a spare render process is created.
>
> Bug: 332435024
> Change-Id: Iebce93f58e73749780bc32389266f0f70b9b3403
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5657751
> Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
> Commit-Queue: Jiacheng Guo <gjc@google.com>
> Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1320224}
Bug: 332435024
Change-Id: Ief73c4c137e99c2cd7dbcb9d985a8f920ed70ecb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5661399
Owners-Override: Danila Kuzmin <dkuzmin@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Danila Kuzmin <dkuzmin@google.com>
Auto-Submit: Danila Kuzmin <dkuzmin@google.com>
Cr-Commit-Position: refs/heads/main@{#1320227}
The CL removes the unnecessary creation of the spare render process on
Android if BFCache is disabled.
The CL also disables the failing test NavigateWithPendingCommit on
android if BFCache is disabled. The issue is happening even without the
feature.
Bug: 348564931, 349487596
Change-Id: Iffe51c8726aa9e753703d8b69ca6bf1fbef23d3b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5657750
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Jiacheng Guo <gjc@google.com>
Cr-Commit-Position: refs/heads/main@{#1320185}
The CL adds the parameter to warm-up a spare render process even if the
speculative RFH creation is deferred. This will boost the navigation on
Android where the creation of the render process is relatively slow.
Bug: 332435024
Change-Id: I32dfe0988d837dec8f7efb1c30afb22c878402ea
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5645306
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Jiacheng Guo <gjc@google.com>
Cr-Commit-Position: refs/heads/main@{#1318975}
The CL adds browser tests for verifying:
* Basic flow when deferring the speculative RFH creation.
* Speculative RFH creation is not deferred for webUI and pages not
requiring a url loader.
* Navigations pending commit will correctly block the speculative RFH
creation.
Bug: 332435024
Change-Id: I7ea1bd4d9decf4710b7a3bde1ec88a42a3df3d3e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5525909
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Jiacheng Guo <gjc@google.com>
Cr-Commit-Position: refs/heads/main@{#1317709}
After the DeferSpeculativeRFH feature, the speculative RFH may not be
created when the navigation starts. The CL adds test utilities to
explicitly wait for the creation of the speculative RFH including:
* New functions added to the TestNavigationManager to wait for the
speculative RFH and acquire the created speculative RFH.
* A new utility class SpeculativeRenderFrameHostObserver to wait for the
speculative RFH without throttling the navigation.
All the failing tests have been modified to cater to the new feature.
The CL for the DeferSpeculativeRFH feature can be found at:
crrev.com/c/5400835
The design doc for the test fixes can be found at:
https://docs.google.com/document/d/14-hslQc3whJ3wa0rse3jdg1pzr5OZUM-5qDOuPAj-8o/edit?usp=sharing
Bug: 332435024
Change-Id: Ib1957784580624cd2546d9dd7d93a27178c879a7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5401150
Reviewed-by: Jan Keitel <jkeitel@google.com>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Jiacheng Guo <gjc@google.com>
Cr-Commit-Position: refs/heads/main@{#1313739}
Suppress unsafe buffer usage on a file-by-file basis. Out of
approximately 5850 .cc and .h files only roughly 160 files fail
compilation with the unsafe buffers warning.
Suppress only, by inserting boilerplate into affected files. Do not
re-write any code to work around the issues. Properly fixing each file
will be done in follow-up CLs.
//content/ is not removed from unsafe_bufers_paths.txt file and will be
also done as a follow-up, so it makes potential reverts simpler.
Bug: 342213636
Change-Id: I4a936e63dea95a78951f7bfae6d5487708ae3c0b
AX-Relnotes: n/a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5608913
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1312393}
