The network service needs access to the permissions policy. Previous CLs
moved all the dependencies so it is now safe to move this class.
The following files need to include permissions_policy.h because
otherwise they want to have access into incomplete `PermissionsPolicy`:
* components/permissions/permission_uma_util.cc
* third_party/blink/common/manifest/manifest_util.cc
* third_party/blink/renderer/core/html/client_hints_util.cc
* third_party/blink/renderer/modules/payments/payment_app_service_worker_registration.cc
* third_party/blink/renderer/modules/payments/payment_instruments.cc
Bug: 382291442
Low-Coverage-Reason: LARGE_SCALE_REFACTOR
Change-Id: Ifcf52df3bc5c035e8f6a45df02cf93f304b748c9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6310821
Auto-Submit: Sandor «Alex» Major <sandormajor@chromium.org>
Owners-Override: Rick Byers <rbyers@chromium.org>
Commit-Queue: Sandor «Alex» Major <sandormajor@chromium.org>
Reviewed-by: Ari Chivukula <arichiv@chromium.org>
Reviewed-by: Rick Byers <rbyers@chromium.org>
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1426391}
When a session is cloned, OnStop isn't called and thus
process descriptor doesn't have process type if it was set
after the tracing session started.
This brings back logic similar to https://chromium-review.googlesource.com/c/chromium/src/+/6163823
with a few difference:
- process type is updated (whereas only the process name was previously set)
- The descriptor is written by TrackNameRecorder
- process labels are kept and emitted in TrackNameRecorder
Change-Id: I65907390d8da74a34359cd2ff5d054a2d20d1be5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6298800
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1425303}
This introduces ClientNavigationThrottler, which is passed a callback that can be either dispatched synchronously or deferred until the client releases the throttle handle, and uses it to defer renderer-initiated navigations until DevTools are done with the dispatch of CDP commands. This should improve CDP API ergonomics in a fairly common case of a CDP client initiating a navigation through a renderer-side CDP command, such as evaluating an element.click() or location.assign(). Since Blink stopped deferring client-initiated navigations some time ago, we used to navigate away before the CDP command returns, so a client would get error messages in response to a command that was, in fact, correctly processed.
Bug: 357977710
Change-Id: I4f28dbf2a0ce5a00c173f99fdde17a16f7352a1c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6271784
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Nate Chapin <japhet@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1424328}
This CL is part of the investigation into replacing
DroppedFrameCounter UKMs with FrameSequenceMetrics.
Details about DFC metrics and why they are redundant
can be found in go/chrome-cc-metrics-refactor.
New Metric Doc: go/chrome-graphics-fsm-as-ukm
Why is this CL so complicated? Approach explained
here: go/chrome-cc-pdf4-as-ukm-why
Bug: 338977417, 395868899
Change-Id: I2a4f222088881f8e58b61b6d55144f91466f808a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6187722
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Ian Clelland <iclelland@chromium.org>
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Commit-Queue: Stacy Gaikovaia <gaiko@google.com>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1422117}
This commit changes the error page for 404 error in IWAs. Previously, it
was generic "This <bundle_id> page can't be found", and now it's the
custom IWA page for errors saying "The page you requested could not be
found in the application".
Bug: 388833752
Change-Id: Ia3d0c3b3e67c20e2b4cf52b3f1862ad15e65af22
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6185412
Reviewed-by: Stefan Zager <szager@chromium.org>
Reviewed-by: Andrew Rayskiy <greengrape@google.com>
Reviewed-by: Kenichi Ishibashi <bashi@chromium.org>
Commit-Queue: Patryk Chodur <pchodur@google.com>
Reviewed-by: Robbie McElrath <rmcelrath@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1421839}
Cross-document navigations only reuse document sequence numbers for
"logically related" navigations. This CL ensures that they are not
reused for cross-origin navigations as well (e.g., about:blank with
different owners), by computing this in the browser process and sending
it in the CommitNavigationParams.
Note that an exception is needed for error pages, which should preserve
the document sequence number and other history item state, though they
transition to and from an opaque origin with the same precursor.
Bug: 40051596
Change-Id: I502251ce12ec8b3e613596b914fbe8a63330b4fc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6185347
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Charlie Reis <creis@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1420736}
To help evaluate future performance improvements in navigation code,
this CL introduces a comprehensive tracing timeline of events
occurring during navigations, as well as new histograms that measure
durations of those events. See the "Request-centric track" proposal in
https://docs.google.com/document/d/1WUTAA9mbsr__prHyYPFPWKqNQpX0x7HVjoYvqt_n_q0/edit?tab=t.0#heading=h.6ejr074unttd
for more information.
Many (but not all) of these events were already logged in other
contexts, but were either not logged for all navigations, or logged
with incorrect timestamps, or both. This is an attempt to log a
comprehensive navigation timeline and corresponding metrics for all
navigations (including no-URLLoader cases, same-document,
etc.). Various existing timestamps are reused when possible, and a
couple of ones that were missing are introduced in this CL. The
closest precedent for this was MaybeRecordTraceEventsAndHistograms(),
which was used as a starting point for this work, but ultimately this
CL diverges too much from it and builds a new mechanism that can
eventually replace that function's metrics and trace events, instead
of attempting to extend it.
Other notes:
- All navigations will now have an entry, labeled as "Navigation:
URL", in a global Navigations track.
- There is a new CommitToDidCommit slice that covers the time from
sending the CommitNavigation IPC to receiving a response for it, and
there is a corresponding RendererCommitToDidCommit slice nested
under it, to depict when the renderer receives that IPC and responds
to it. This allows comparing actual commit processing time to the
time potentially spent on setting up the renderer process or setting
up other renderer-side state like provisional frames.
- Analyzing traces has shown that
DidCommitProvisionalLoadParams::commit_navigation_end was actually
not an accurate timestamp of when the renderer responds to
CommitNavigation, so a new timestamp was introduced for that.
- A navigation commit actually lasts beyond NavigationRequest
destruction, all the way to the end of
RFHI::DidCommitNavigation(). DidCommitNavigation() involves a
non-trivial amount of work and should be measured in its entirety,
because while the renderer process isn't blocked by the work the
browser process does at DidCommit time and can make progress towards
first paint as soon as it sends the DidCommit IPC, we do care about
when the browser process is done processing DidCommit, so that it
can handle additional tasks in the new document. Therefore, the
navigation timeline is actually logged at the end of
DidCommitNavigation using timestamps collected throughout the
lifetime of a navigation.
To make this possible, a new NavigationRequest::Timeline struct is
introduced to collect all the timestamps in one place, allowing them
to be used after NavigationRequest destruction. This is somewhat
similar to the NavigationHandleTiming struct, but unfortunately that
struct is difficult to extend for use in this CL, as its timestamps
are exposed to embedders through content/public, making them tricky
to replace in cases where they aren't conveying the right time
(e.g., navigation_did_commit_time is not "The time the DidCommit
navigation message is received" as its comment suggests, as it's
actually taken in the middle of RFHI::DidCommitNavigation() in
NavigationRequest::DidCommitNavigation()).
- Two more timestamps were added for NavigationRequest creation and
for when the response to CommitNavigation IPC is received. Note that
this response can currently be either a mojo reply to the
CommitNavigation IPC or a standalone DidCommitNavigation IPC; both
of these paths call RenderFrameHostImpl::DidCommitNavigation().
- Navigations that don't go through NavigationURLLoader (e.g.,
browser-initiated same-doc or about:blank navigations) will log one
BeginNavigationToCommit slice, in place of
BeginNavigationToLoaderStart and the various loader slices.
- When the browser learns about a navigation at DidCommit time (e.g.,
renderer-initiated same-doc navigations, synchronous about:blank
commits), only the top-level navigation event is logged (with the
proper start-to-finish time), with no further breakdown into slices,
as all of the work happens within DidCommitNavigation in that case.
- For now, bfcache and prerender activations only have the top-level
navigation event, with no further BeginNavigationToLoaderStart into
nested slices. This will be improved in followups.
A couple of sample traces:
NavigateABCToABD test with various browser-initiated navigations:
https://ui.perfetto.dev/#!/?s=5361eed769e4be363b10d7a0b8c7a3decfc89702
Browser-initiated about:blank (first navigation), synchronous
about:blank commit (second navigation), from
DocumentTokenBrowserTest.NewWindowSyncCommit:
https://ui.perfetto.dev/#!/?s=5f49bf530c9703f95d8bc13c04a8cf9b89be5715
Change-Id: I2597e9e92db6a054f959fcd5052b2a869a6e1ec6
Bug: 382303496
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6092101
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Chris Thompson <cthomp@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1415219}
This concept has been misnamed until now, since the current and pending
history list offsets passed through the navigation stack are actually
indices into the history list, rather than offsets (e.g., +1, -1) from
the current index.
This CL renames them to reduce confusion, without changing behavior.
Bug: 382303496
Change-Id: I19215ec70a49e28a02b2171d4e8a57a47fb85697
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6205129
Commit-Queue: Charlie Reis <creis@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1414288}
This reverts commit 0e5d5e26ab.
Reason for revert:
Causes flaky failures of
PrerenderBrowserTest.CancelOnSpeculationCandidateRemoved
on many bots. On some bots, like Linux CFI, it seems to fail more than half the time.
Bug: 392578265
Original change's description:
> preloading: Firing pagehide when prerendering
>
> This CL makes prerender cancellation fire pagehide by calling
> RenderFrameHostImpl::ClosePage when the prerendered page is
> intentionally canceled (such as removing speculation rules,
> not by failure).
> Another CL https://crrev.com/c/6197678 is created as a follow-up to
> support the new-tab cases.
>
> Bug: 353628449
> Change-Id: Ie2903ec3d0782c102181bccc3ec3d6910207481e
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6108648
> Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
> Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
> Commit-Queue: Huanpo Lin <robertlin@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1411504}
Bug: 353628449
Change-Id: I3c98c3fd04ad6fa3dd3749ea379512f261d95dfb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6203506
Auto-Submit: Mark Pearson <mpearson@chromium.org>
Owners-Override: Mark Pearson <mpearson@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Mark Pearson <mpearson@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1411932}
This CL makes prerender cancellation fire pagehide by calling
RenderFrameHostImpl::ClosePage when the prerendered page is
intentionally canceled (such as removing speculation rules,
not by failure).
Another CL https://crrev.com/c/6197678 is created as a follow-up to
support the new-tab cases.
Bug: 353628449
Change-Id: Ie2903ec3d0782c102181bccc3ec3d6910207481e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6108648
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Huanpo Lin <robertlin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1411504}
This commit completes work started in two previous commits:
- https://crrev.com/c/5896651, which added the ability to generate a
Mojo struct containing WebUI resource metadata (URL path to resource
ID mapping, i18n string replacements, etc.) in the browser process
- https://crrev.com/c/5955670, which adds an implementation of an
in-process resource loader for use in the renderer process.
This commit has the browser process generate WebUI resource metadata and
send it to WebUI renderer processes. The renderer process then uses this
metadata to construct an in-process resource loader with the ability to
retrieve resources directly from the memory-mapped 'resources.pak' file.
All of this happens if and only if the WebUIInProcessResourceLoading
base::Feature is enabled. This is disabled by default, so this commit
does not change the production codepath.
This commit adds the aforementioned Mojo struct and in-process resource
loader implementation to the binary all at once, so the 32KB Fuchsia
binary size increase is actually the result of 3 separate commits.
Fuchsia-Binary-Size: See commit description.
Bug: 362511750
Change-Id: I90991b35eb7f637d5ad651d4fc4e173a06121bc9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5955234
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Alex Yang <aycyang@chromium.org>
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#1406831}
- Remove IS_CHROMEOS_LACROS code
- Replace IS_CHROMEOS_ASH with the equivalent IS_CHROMEOS
- Similarly for is_chromeos_lacros/is_chromeos_ash.
- Drop obsolete includes/build dependencies.
- Drop lacros-chrome browser tag from gpu tests
- Drop obsolete skip directives from gpu tests
No change in behavior.
Bug: b:365742770 , b:365741912
AX-Relnotes: n/a.
Change-Id: I594d3677a9855d0649deba3ad836a1b3804440f1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6097832
Reviewed-by: Hidehiko Abe <hidehiko@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1398368}
This implements the following behaviour (behind kGuestViewMPArch):
- attaches guests in FrameAutoAttacher
- updates in RFDAH to correctly expose guest target information
- sets the placeholder RemoteFrame's devtools_frame_token with the
guest's main frame's devtools_frame_token after the guest is
attached
Still TODO:
- support inspecting new guests added & waitForDebugger
See bug for design doc.
Bug: 376084061
Change-Id: I326fe0dfe0a6e3a33a3dd2806b69efc239c23af1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6050701
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Adithya Srinivasan <adithyas@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Joe Mason <joenotcharles@google.com>
Cr-Commit-Position: refs/heads/main@{#1395977}
Previously we would try to differentiate pointer interactions which
happened to have pointermove events, and assumed that these were "drag"
vs tap or click. However, this never quite worked, as it is very common
to have a tiny bit of pointermove even for a tap (threshold distance).
Also, even the value of this feature is minimal, as "drag" itself can
vary a lot and we only sometimes measure some parts of drag interactions.
We are just going to remove this attempt to differentiate.
Bug: 40930016, 382949422
Change-Id: I009f83779f1d04f31f9216bd52c9d4089a2d66ea
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6059123
Reviewed-by: Mikhail Khokhlov <khokhlov@google.com>
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Reviewed-by: Noam Rosenthal <nrosenthal@chromium.org>
Reviewed-by: Joe Mason <joenotcharles@google.com>
Commit-Queue: Michal Mocny <mmocny@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1395225}
Add Assign(Span) and Append(span) and drop the pointer+size variants.
Drop the templated constructors and operator= because such users can
trivially be converted to use the span<const uint8_t> constructor
instead.
For content::DecodeImage, pass the data to decode as a span instead of
as a pointer+size.
Bug: 40285824, 351564777
Change-Id: If2ddf008481fce5bfea47fc35234f5bdf29e8046
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6084896
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Auto-Submit: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/main@{#1394441}
We categorize navigations as duplicate if the URL and other params are
the same and the start time of the new navigation is close to the start
time of the older navigation. In that case, we can ignore the new
navigation in favor of the old navigation.
Now, we want to see how many potentially duplicate navigations there
are that doesn't fall under the start time threshold that we have
(which defaults to 2000ms). To do this, this CL updates the metrics
related to duplicate navigations to still record even if the navigation
start time diff is not under threshold. Note that this is only for
metric recording purposes, and we will still only ignore navigations
whose start time diff is under threshold.
OBSOLETE_HISTOGRAMS=Old duplicate nav histograms are removed in favor
of the new ones.
Bug: 366060351
Change-Id: Ie8e26300816dfaed102c0e77b62178c484f67f7a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6076361
Reviewed-by: Jiacheng Guo <gjc@google.com>
Auto-Submit: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Jiacheng Guo <gjc@google.com>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1392749}
In most cases NOTREACHED() is now a better option. Also performs
dead-code removal.
Bug: 40122554
Low-Coverage-Reason: OTHER Should-be-unreachable code
Change-Id: I3d9054619242c472feadab98d9de4024c74d4992
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6013928
Commit-Queue: Avi Drissman <avi@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Auto-Submit: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1385678}
NOTREACHED() and NOTREACHED_IN_MIGRATION() are both CHECK-fatal now.
The former is [[noreturn]] so this CL also performs dead-code removal
after the NOTREACHED().
This CL does not attempt to do additional rewrites of any surrounding
code, like:
if (!foo) {
NOTREACHED();
}
to CHECK(foo);
Those transforms take a non-trivial amount of time (and there are
thousands of instances). Cleanup can be left as an exercise for the
reader.
This does clean up kCrashOnDanglingBrowserContext as both paths of the
kill switch are currently fatal. This has been rolled out for a long
time.
Bug: 40580068, 40062641
Change-Id: Ib88e710d003e2e48df3fc502ca54d2341d157a0e
Cq-Include-Trybots: luci.chromium.try:linux-dcheck-off-rel
Low-Coverage-Reason: OTHER Should-be-unreachable code
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5974816
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Auto-Submit: Peter Boström <pbos@chromium.org>
Reviewed-by: Sam McNally <sammc@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1376522}
We are seeing reports of pending commit RFHs getting calls that should
not come from provisional RenderFrames, e.g. DispatchLoad. This CL adds
CHECKs on the renderer-side of these calls to see if the problem lies
on the renderer side.
Bug: 368267149
Change-Id: If36c085d47c03fc53377c2780975d65623deb03a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5974817
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1375615}
Move some more blink media code into platform/media from public/platform/media. This allows us to use KURL directly and
not go to a WebURL on some calls.
Apply INSIDE_BLINK macro to other code that is in platform/media so
it will use the internal types. This is necessary because this code uses
blink mojom types and we want to enforce that blink mojo headers are
only included inside blink. Fortunately this addresses some of the
discouraged type overrides in the media code.
BYPASS_LARGE_CHANGE_WARNING=File move
Change-Id: I712128d82bb7e1971548f22aaadfdf31a7393ad6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5962517
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1374973}
Deleting a (non-provisional) main frame is problematic and leads to
non-deterministic crashes in later tasks. This was the source of many
longstanding crash bugs in the past, which are believed to all be fixed.
Enable this CHECK (with a delayed rollout) on Android as well now, since
there is no actual reason why Android behaviour should differ.
Bug: 40063628
Bug: 40606576
Bug: 40076091
Bug: 40091257
Change-Id: I026cdf05b793b8c1100f313f2f200e6b85444692
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5973296
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1374886}
Between RenderDocument and SiteInstanceGroup, navigations that are
same-process can now be cross-SiteInstance. As a result, we now create
new RenderFrameImpls for the navigations, and the associated objects.
One such object is NavigationState, which tracks
was_initiated_in_this_frame. Not persisting this value across
navigations means that an extra DidStartNavigation event gets fired.
This Cl persists this value across RenderFrames by copying it from the
previous NavigationClient when creating and binding a new
NavigationClient.
With SiteInstanceGroup enabled, http/tests/loading/simple-subframe.html
fails with an extra DidStartNavigation event.
http/tests/loading/redirect-methods.html previously had extra
DidStartNavigation events added to to account for this. Those extra
events can now be removed. See https://crrev.com/c/5373697.
Test: See above
Bug: 40269084, 40615943
Change-Id: I8dd86d503b0cea0ec38957285dac56238a44523a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5917334
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Sharon Yang <yangsharon@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1374779}
On LocalFrame <-> LocalFrame swaps for local root frames, we will
destruct the previous compositor before committing the new document.
Actions like releasing the LayerTreeFrameSink might block the main
thread and regress LCP. To prevent that from happening, this CL
introduces a way to keep the previous document's LayerTreeView
alive by moving its ownership to a task posted to delete
it after some delay (defaulting to 1000ms), instead of immediately
deleting it on widget destruction.
Bug: 936696
Change-Id: I2a5683ba80c959205e66a8ed6d6820f5af77e842
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5938512
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1373659}
This is a reland of commit 33493d2d85
This restores a branch in RenderViewHostImpl::CreateRenderView() that
was mistakenly removed in the original CL.
Original change's description:
> [prerender] Fix crash when discarding a speculative main RenderFrameHost
>
> Previously, starting a prerender navigation would create a speculative
> RenderFrameHost for the root frame tree node in the browser process.
> However, the corresponding RenderFrame in the renderer process would
> be created as the active/current main RenderFrame. This is a result of
> the interaction between `CreateProxiesForSiteInstanceGroup()`, which
> skips creating a proxy if it thinks the early commit optimization will
> be used, and `PerformEarlyRenderFrameHostSwapIfNeeded()`, which skips
> performing early commits in prerendering frame trees.
>
> Intentional or not, this is problematic because:
>
> - The browser process assumes speculative RenderFrameHosts can be
> cleaned up by deleting the corresponding RenderFrame in the renderer
> process.
> - The renderer process assumes the active/current main RenderFrame is
> never explicitly deleted, and that it will only be implicitly deleted
> as a side effect of explicitly deleting its blink::WebView.
> - Blink assumes a blink::WebView always has an active main frame (i.e.
> non-null). Rather than crashing non-deterministically, the renderer
> process CHECK-fails if the browser tries to explicitly delete a
> non-provisional main RenderFrame.
>
> Taken together, this means discarding a speculative main RenderFrameHost
> during a prerender navigation will crash the renderer process. Needless
> to say, this is not desirable. Previous fixes have centered around
> identifying the cases that would discard a speculative RenderFrameHost
> and disabling prerendering for those cases.
>
> However, this doesn't fix the underlying issue and ends up being a game
> of whack-a-mole. This CL implements a proper fix: the corresponding
> main RenderFrame in the renderer process is now created as a provisional
> frame during a prerender navigation. This is implemented using a
> placeholder RemoteFrame; RenderDocument already uses this concept for
> local -> local frame swaps.
>
> This CL also refactors several ancillary components to make the updated
> logic easier to follow:
>
> - Rather than using a non-null `previous_frame_token` as the implicit
> signal for creating a provisional main local frame, Mojo now uses the
> CreateProvisionalLocalMainFrameParams variant subtype to convey this
> intent. This is a required cleanup, since prerender navigations should
> not set a `previous_frame_token`, but still want the placeholder
> RemoteFrame + provisional LocalFrame behavior.
> - With the updated union, the different main frame cases are also broken
> out more distinctly in `AgentSchedulingGroup::CreateView()`.
> - Rename `EnsureWidgetInitialized()` to `InitializeWidgetAtSwap()`,
> since that is the only situation it is called.
> - Remove `previous_frame_token_for_compositor_reuse` from the frame
> widget creation params, and replace it with the `reuse_compositor`
> bool. The frame token is redundant, since the frame widget creation
> params are always paired with frame creation params.
> - Refactor `WillDetach()` and `InitializeWidgetAtSwap()` to account for
> the removal of `previous_frame_token_for_compositor_reuse`. It turns
> out the renderer process already has all the information needed to
> determine the previous frame; passing it directly significantly
> simplifies this coordination.
>
> Finally, this also removes the crash instrumentation that was previously
> added to help track down situations where prerender navigations would
> discard speculative main RenderFrameHosts. Since this no longer crashes,
> the instrumentation is no longer needed.
>
> Bug: 40076091
> Change-Id: I1c19853c75580492653e608afb1db3442a264b3a
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5922799
> Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
> Commit-Queue: Daniel Cheng <dcheng@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1369647}
Bug: 40076091
Change-Id: I10ecdf8233f6dfd42e0478c819447831d50256c3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5937586
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1369798}
This reverts commit 33493d2d85.
Reason for revert: CL has bug :)
Original change's description:
> [prerender] Fix crash when discarding a speculative main RenderFrameHost
>
> Previously, starting a prerender navigation would create a speculative
> RenderFrameHost for the root frame tree node in the browser process.
> However, the corresponding RenderFrame in the renderer process would
> be created as the active/current main RenderFrame. This is a result of
> the interaction between `CreateProxiesForSiteInstanceGroup()`, which
> skips creating a proxy if it thinks the early commit optimization will
> be used, and `PerformEarlyRenderFrameHostSwapIfNeeded()`, which skips
> performing early commits in prerendering frame trees.
>
> Intentional or not, this is problematic because:
>
> - The browser process assumes speculative RenderFrameHosts can be
> cleaned up by deleting the corresponding RenderFrame in the renderer
> process.
> - The renderer process assumes the active/current main RenderFrame is
> never explicitly deleted, and that it will only be implicitly deleted
> as a side effect of explicitly deleting its blink::WebView.
> - Blink assumes a blink::WebView always has an active main frame (i.e.
> non-null). Rather than crashing non-deterministically, the renderer
> process CHECK-fails if the browser tries to explicitly delete a
> non-provisional main RenderFrame.
>
> Taken together, this means discarding a speculative main RenderFrameHost
> during a prerender navigation will crash the renderer process. Needless
> to say, this is not desirable. Previous fixes have centered around
> identifying the cases that would discard a speculative RenderFrameHost
> and disabling prerendering for those cases.
>
> However, this doesn't fix the underlying issue and ends up being a game
> of whack-a-mole. This CL implements a proper fix: the corresponding
> main RenderFrame in the renderer process is now created as a provisional
> frame during a prerender navigation. This is implemented using a
> placeholder RemoteFrame; RenderDocument already uses this concept for
> local -> local frame swaps.
>
> This CL also refactors several ancilliary components to make the updated
> logic easier to follow:
>
> - Rather than using a non-null `previous_frame_token` as the implicit
> signal for creating a provisional main local frame, Mojo now uses the
> CreateProvisionalLocalMainFrameParams variant subtype to convey this
> intent. This is a required cleanup, since prerender navigations should
> not set a `previous_frame_token`, but still want the placeholder
> RemoteFrame + provisional LocalFrame behavior.
> - With the updated union, the different main frame cases are also broken
> out more distinctly in `AgentSchedulingGroup::CreateView()`.
> - Rename `EnsureWidgetInitialized()` to `InitializeWidgetAtSwap()`,
> since that is the only situation it is called.
> - Remove `previous_frame_token_for_compositor_reuse` from the frame
> widget creation params, and replace it with the `reuse_compositor`
> bool. The frame token is redundant, since the frame widget creation
> params are always paired with frame creation params.
> - Refactor `WillDetach()` and `InitializeWidgetAtSwap()` to account for
> the removal of `previous_frame_token_for_compositor_reuse`. It turns
> out the renderer process already has all the information needed to
> determine the previous frame; passing it directly significantly
> simplifies this coordination.
>
> Finally, this also removes the crash instrumentation that was previously
> added to help track down situations where prerender navigations would
> discard speculative main RenderFrameHosts. Since this no longer crashes,
> the instrumentation is no longer needed.
>
> Bug: 40076091
> Change-Id: I1c19853c75580492653e608afb1db3442a264b3a
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5922799
> Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
> Commit-Queue: Daniel Cheng <dcheng@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1369647}
Bug: 40076091
Change-Id: Ic6caff54e1d3085603809fdefb036b277c4720d5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5938653
Auto-Submit: Daniel Cheng <dcheng@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1369651}
Previously, starting a prerender navigation would create a speculative
RenderFrameHost for the root frame tree node in the browser process.
However, the corresponding RenderFrame in the renderer process would
be created as the active/current main RenderFrame. This is a result of
the interaction between `CreateProxiesForSiteInstanceGroup()`, which
skips creating a proxy if it thinks the early commit optimization will
be used, and `PerformEarlyRenderFrameHostSwapIfNeeded()`, which skips
performing early commits in prerendering frame trees.
Intentional or not, this is problematic because:
- The browser process assumes speculative RenderFrameHosts can be
cleaned up by deleting the corresponding RenderFrame in the renderer
process.
- The renderer process assumes the active/current main RenderFrame is
never explicitly deleted, and that it will only be implicitly deleted
as a side effect of explicitly deleting its blink::WebView.
- Blink assumes a blink::WebView always has an active main frame (i.e.
non-null). Rather than crashing non-deterministically, the renderer
process CHECK-fails if the browser tries to explicitly delete a
non-provisional main RenderFrame.
Taken together, this means discarding a speculative main RenderFrameHost
during a prerender navigation will crash the renderer process. Needless
to say, this is not desirable. Previous fixes have centered around
identifying the cases that would discard a speculative RenderFrameHost
and disabling prerendering for those cases.
However, this doesn't fix the underlying issue and ends up being a game
of whack-a-mole. This CL implements a proper fix: the corresponding
main RenderFrame in the renderer process is now created as a provisional
frame during a prerender navigation. This is implemented using a
placeholder RemoteFrame; RenderDocument already uses this concept for
local -> local frame swaps.
This CL also refactors several ancilliary components to make the updated
logic easier to follow:
- Rather than using a non-null `previous_frame_token` as the implicit
signal for creating a provisional main local frame, Mojo now uses the
CreateProvisionalLocalMainFrameParams variant subtype to convey this
intent. This is a required cleanup, since prerender navigations should
not set a `previous_frame_token`, but still want the placeholder
RemoteFrame + provisional LocalFrame behavior.
- With the updated union, the different main frame cases are also broken
out more distinctly in `AgentSchedulingGroup::CreateView()`.
- Rename `EnsureWidgetInitialized()` to `InitializeWidgetAtSwap()`,
since that is the only situation it is called.
- Remove `previous_frame_token_for_compositor_reuse` from the frame
widget creation params, and replace it with the `reuse_compositor`
bool. The frame token is redundant, since the frame widget creation
params are always paired with frame creation params.
- Refactor `WillDetach()` and `InitializeWidgetAtSwap()` to account for
the removal of `previous_frame_token_for_compositor_reuse`. It turns
out the renderer process already has all the information needed to
determine the previous frame; passing it directly significantly
simplifies this coordination.
Finally, this also removes the crash instrumentation that was previously
added to help track down situations where prerender navigations would
discard speculative main RenderFrameHosts. Since this no longer crashes,
the instrumentation is no longer needed.
Bug: 40076091
Change-Id: I1c19853c75580492653e608afb1db3442a264b3a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5922799
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1369647}
This CL removes no-longer-used headers from
RenderAccessibilityImpl and related files. A few consumers of
render_accessibility_impl.h needed to have some additional
includes added for IWYU.
This CL also removes load_inline_text_boxes_ids_ from
RenderAccessibilityImpl, as that isn't used anywhere.
No behavioral changes are expected.
AX-Relnotes: n/a
Change-Id: Ifbc871477830301d89654c393d2e7e77697ad2ff
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5901000
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Stefan Zager <szager@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Kurt Catti-Schmidt <kschmi@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1363135}
This reduces some flaky tests when a race condition happens and a full serialization occurs that needed info from the location updates.
If we're sending a full serialization anyways it actually makes sense to use one serialization than two seperate ones anyways.. Less overhead.
Change-Id: Ie64acd34e6da92344b423dc013ba40497e5d17d0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5878322
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Dominic Farolino <dom@chromium.org>
Reviewed-by: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Ahmed Elwasefi (Ahmad45123) <a.m.elwasefi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1362560}
SerializeFrame now returns serialized resources in a callback.
A subsequent change will take advantage of this and fetch some
resources asynchronously.
This change should be a no-op.
Bug: 363289333
Change-Id: If00c8b47add50e384921c29e2a88a167b5b4a058
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5899715
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Dan H <harringtond@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1362478}
Now that we don't have any reports for browser vs renderer calculated
origin mismatch, we can start setting origin_to_commit in
CommitNavigationParams for all cases, to be used by the renderer
in all cases (except when inheriting bits like document.domain).
This behavior is protected behind a flag.
Bug: 888079
Change-Id: I782ad14713c1228f46fea8347121784a3cfc5c07
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5873739
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1360576}
Duplicate navigations are navigations that are the same as the
current ongoing navigations, and likely to be triggered accidentally
by e.g. double link/button clicks. This CL makes it so that we
record duplicate navs as a separate NavigationDiscardReason.
Also, currently when a new renderer-initiated navigation is
triggered while there is already another navigation initiated by
the same renderer ongoing, the older navigation is canceled by
overwriting the NavigationClient. This cancellation is incorrectly
marked as kInternalCancellation because the overwrite didn't
set a reason. This CL fixes that by setting the reason to
indicate that the navigation client is disconnected because of
a new navigation / duplicate navigation. This CL also makes
form submission-initiated cancellation mark the disconnection
correctly (as "new navigation").
Bug: 366060351
Change-Id: I084ca4dbd56805192cf4d553ab866e011d7d1917
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5856745
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1355642}
Given the high volume of reports, try to avoid a renderer crash when a
same-document navigation fails to commit because no current history item
exists in the renderer process. Instead, restart the navigation as
cross-document and send a DumpWithoutCrashing report for now.
Crash keys included:
* history_no_item-is_main_frame: Main frame vs subframe.
* history_no_item-renderer_commit_state: Whether renderer is still on
initial empty document (0), or in a different NavigationCommitState.
* history_no_item-browser_history_offset: Browser's view of current
history index.
* history_no_item-browser_history_len: Browser's view of history length.
* history_no_item-renderer_history_len: Renderer's view of history
length.
Bug: 41489044
Change-Id: I294ac92e6fb2682e5c2b4adbe3040fb0fff0f201
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5859355
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1355430}
We currently ignore duplicated link clicks in favor of continuing the
older navigation. This CL expands this behavior to non-link click
navigations, both on the renderer and the browser side. Also adds
a histogram to see how often we hit the duplicated case, and a
timeout threshold for categorizing two navigations as duplicates,
set to 2000ms by default.
Bug: 366060351
Change-Id: Ic65c05217ef52a72f8ee0aa07c4be6c94b13caa5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5856811
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1355065}
If 2 link clicks to the same URL happens on the same time, it's likely
that it is caused by accident. We probably should keep the first
navigation since they will most likely result in the same page.
This CL adds the logic to do that, protected behind a flag.
Bug: 366060351
Change-Id: I344fcfbf0831b0fa16fcb19b8695f2986a1cf612
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5837959
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1354370}
https://chromium-review.googlesource.com/c/chromium/src/+/5801311/4/content/renderer/render_frame_impl.cc#5516 accidentally switched from checking the WebUI bindings to checking for any bindings.
If we write a script like window.location.href = "/test.html" in the head section, the expected behavior is that `DOMContentLoaded` will not be triggered due to the early redirection. However, due to the above error, OpenURL will be called in the Browser, resulting in render not being detached immediately, so the DOM will be fully loaded.
This CL fixes the issue by checking the same two WebUI bindings as the original code did.
Bug: 365712501
Change-Id: Ic1769a64b8b89d08b50255c5aa810b0f5a83f5c2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5850489
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: q lamry <zhaoy@microsoft.com>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1353727}
