Addresses ~14% of `-WUnsafe-buffer-usage` opt-out in `//content`.
This is a #cleanup.
The patch was initially partially generated by `./tool/clang/spanify`.
This patch applies conversions specifically to c-arrays in `//content`.
Although the `spanify` tool supports broader conversions, this change
intentionally focuses on c-arrays. Several manual fixes were made to
address anonymous struct issues and other edge cases encountered during
the conversion process.
Bug: 342213636, 40285824
Change-Id: I72666faa45a461ea27bb3608beeacc6c9fcd8a63
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5824992
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1349804}
1. This CL intend to remove the first-party ReduceAcceptLanguage
origin trial which was introduced by https://crrev.com/c/3932979
years ago.
2. To support experiment the ReduceAcceptLanguage, we also add supports
first part and third party deprecation origin trial for this feature.
* Same origin: We support most cases (subresource, iframe, etc) of
same origin deprecation trial. Also, to make the first request work, sites can send the critical-origin-trial header.
* Cross origin: For cross origin iframe deprecation origin trial, site
need to register first-part deprecation origin trial. For subresource, sites can use JavaScript to inject the origin-trial meta tag.
* Same origin redirect: The expected behavior will happen in the second request, e.g. if the first request opt-in the deprecation origin trial, starting the second request we won't send reduced accept-language.
* Cross origin redirect: The deprecation origin trial won't work when a.com redirects to b.com and only a.com opt-in the deprecation origin,
because persistent origin trials only parse and persist tokens for commit origin which is b.com in this case.
Change-Id: Ia1fda573bb0279a4b976a7a3b8455bdcb809fcce
Bug: 334954143
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5582436
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Victor Tan <victortan@chromium.org>
Reviewed-by: Andrew Williams <awillia@chromium.org>
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1314865}
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}
From the existing metric, we can see there is a small number of profile
that user's accept-language is empty, this could cause the DCHECK failed
and result a crash. In this case, we can skip reduce the accept-language
instead of ending with a crash.
Also, ChromeOs had similar crash crbug.com/1151558 related to
AcceptLanguage prefs which marked as won't fixed.
This CL also adds a metric to tracking how often this case can happen when reducing accept-language.
LanguageUsage.AcceptLanguage.Count:
http://uma/p/chrome/timeline_v2?sid=61a87ff670d6e5cc43c62030d34ed552
Change-Id: Iba27af6cbbf9a02c0c4f2c511c58c1abc3d27759
Bug: 337741702
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5506595
Reviewed-by: Andrew Williams <awillia@chromium.org>
Reviewed-by: Clark DuVall <cduvall@chromium.org>
Commit-Queue: Victor Tan <victortan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1295482}
The canonical bug format is TODO(crbug.com/<id>). TODOs of the
following forms will all be migrated to the new format:
- TODO(crbug.com/<old id>)
- TODO(https://crbug.com/<old id>)
- TODO(crbug/<old id>)
- TODO(crbug/monorail/<old id>)
- TODO(<old id>)
- TODO(issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/u/1/issues/<old id>)
- TODO(bugs.chromium.org/<old id>)
Bug id mapping is sourced from go/chrome-on-buganizer-prod-issues.
See go/crbug-todo-migration for details.
#crbug-todo-migration
Bug: b/321899722
Change-Id: Ifd155bbeff882ea939f74cf8b8f847f42847940b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5468156
Reviewed-by: Darryl James <dljames@chromium.org>
Owners-Override: Alison Gale <agale@chromium.org>
Commit-Queue: Alison Gale <agale@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1290297}
Remove `defer` from
`URLLoaderThrottle::BeforeWillProcessResponse` and
`URLLoaderThrottle::BeforeWillRedirectRequest`
as they are not used.
This removes `DEFERRED_BEFORE_RESPONSE` as well.
Remove `URLLoaderThrottle::Delegate::RestartWithURLResetAndFlags`,
and instead signal a restart by setting `RestartWithURLReset` to true
in `BeforeWillProcessResponse` or `BeforeWillRedirectRequest`,
because and to clarify `RestartWithURLReset` can be set only
synchronously within these methods.
Remove `pending_restart_flags_`.
(`RestartWithURLResetAndFlags()` was always called with 0)
Remove `throttle_will_start_original_url_`
(always true when `RestartWithURLResetNow()` is called)
Remove `has_pending_restart_`, and use `RestartWithURLReset` local
variables instead, because Before* methods can no longer defer the
loading and thus restarting is processed immediately.
Bug: 325314722
Change-Id: Ia520d055966d03a2cb402f961afd837b74683796
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5149865
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Lingqi Chi <lingqi@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1263152}
Initial empty documents are assigned a new UKM source ID in blink.
Previously, this source ID was not propagated to the browser. Hence it
was impossible to attribute metrics reported by such initial empty
documents.
This CL plumbs the UKM source ID for the initial empty document of a
child frame in the CreateChildFrame mojo message, so that the browser
process knows about it and can report an appropriate DocumentCreated
metric for the Identifiability Study.
We explicitly skip reporting the corresponding DocumentCreated event
to UKM in this case, see https://crbug.com/1326431 for more
explanation.
Note that this CL still does not do anything for the initial empty
document of popups. However, in such case, the top-level URL is anyway
about:blank, so attributing those metrics is not super helpful.
Bug: 1326431
Change-Id: I358cdf762bca8925755a9679b33d96660616657d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3934274
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Reviewed-by: Yue Ru Sun <yrsun@chromium.org>
Commit-Queue: Antonio Sartori <antoniosartori@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1077331}
This patch is a no-op with all the common build flags.
Add the "DanglingUntriaged" raw_ptr annotation. It indicates a raw_ptr
becomes dangling, and it should be triaged/fixed. This will also disable
dangling protection for those pointers, once enabled.
These were identified by running the linux-lacros-rel CQ bot with DPD
activated (both build + runtime here: https://crrev.com/c/3941825)
Bug: 1291138
Change-Id: Id00ef560214bcc3ce1e38fd97e84f1e733586703
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4027920
Commit-Queue: Ali Hijazi <ahijazi@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Owners-Override: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1072127}
browsing_context_state.h includes browsing_instance.h but would be fine
with just BrowsingInstanceId. This include is used unknowingly
by other files that construct BrowserContext's sometimes without even
importing browsing_context_state.h in the first place.
Replace browsing_instance.h import by browsing_instance_id.h and
add explicit dependencies where needed.
Change-Id: I629af039b886aa0ce37a3faab1007aca24ffbfbe
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3926070
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1054176}
== Background ==
blink::DocumentToken will be used for features like GPU's pipeline
caching, allowing the cache to be partitioned using storage keys. The
renderer process is considered untrustworthy, but communicates directly
with the GPU process; rather than having the untrustworthy renderer
directly specify a potentially spoofed storage key, it will send a
document token to the GPU process, which will then ask the trustworthy
browser process for the corresponding storage key.
== Implementation details ==
On the browser side, the blink::DocumentToken is bound to the
RenderFrameHostImpl's DocumentAssociatedMetadata; on the renderer side,
the token is bound to the blink::Document.
When creating a new window or child frame, the browser side allocates a
new DocumentToken and also passes that token to the renderer to plumb
through frame initialization.
When committing a new navigation, the browser side allocates a new
DocumentToken on the NavigationRequest and passes that token to the
renderer in the `CommitNavigation()` IPC.
The intended behavior is that blink::DocumentToken changes each time the
Document changes, though there are some exceptions:
- things like javascript: URLs that end up resulting in a new document
reuse the old DocumentToken: from the perspective of the browser, the
document has not really changed.
- when processing something like `window.open()`, Blink has a historical
quirk where it creates the initial empty document and then immediately
replaces it with a synchronously-completed navigation to about:blank.
Like javascript: URLs, this also reuses the old DocumentToken: this
quirk is renderer-internal and invisible to the browser.
There is also a small hack for speculative RenderFrameHosts: committing
a navigation in a speculative RenderFrameHost does not construct a new
DocumentAssociatedMetadata, instead, the DocumentAssociatedMetadata's
token is simply updated. The hope is that there will be minimal other
document-associated data prior to committing a navigation in a
speculative RenderFrameHost, so this quirk will be mostly invisible
outside the //content implementation.
One open question: when navigating away from the initial empty document
and reusing the Window object, should the DocumentToken be reused
instead of generating a new one? Reusing the token would more closely
mirror the lifetime of LocalDOMWindow and allow it to be a logical
replacement for LocalFrameToken in ExecutionContextToken; however,
reuse of the Window object is also one of the weird edge cases in the
HTML standard that would be nice to minimize if possible.
For now, the implementation chooses not to reuse the DocumentToken even
if the LocalDOMWindow would be reused for a navigation from the initial
empty document to another same-origin page (note that this is distinct
from the synchronous re-navigation to about:blank noted above).
Finally, this CL does not add the ability to look up a RenderFrameHost
by DocumentToken yet: this CL is already far too large due to the amount
of boilerplate changes required.
Bug: 1362938
Change-Id: I4431ed4a7a0739905579fd1585b2a42701d84d7d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3849601
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Nate Chapin <japhet@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1050447}
