Noise tokens will be used as a randomized identifier for Canvas noising.
As Canvas noising is intended to be web-platform wide, we add the
following additions into both //content and //third_party/blink.
The CanvasNoiseTokenManager is a browser-sided token generator that
manages noise tokens generated once per BrowserContext instance,
meaning, each browser session/profile will generate its own noise token.
This noise token is then piped to the renderer using
RendererPreferences. On the Blink side, a frame-local global,
called CanvasNoiseToken, will store the noise token.
Bug: 392627601
Change-Id: I9292cdd8087741dc2d1cb743caeaea3050014f3d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6226586
Reviewed-by: Giovanni Ortuno Urquidi <ortuno@chromium.org>
Commit-Queue: John Kim <johnykim@google.com>
Reviewed-by: Antonio Sartori <antoniosartori@chromium.org>
Reviewed-by: Tom Van Goethem <tov@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1435582}
"Selection" is a term that has a loaded meaning in autofill for a
specific phase of the UI selection (i.e. "hovering"), so renaming this
callback to be more specific and to match the terminology used in
autofill.
Bug: 380367784
Change-Id: I4c7b6ddb8ae016ca38e0df2074f84f8b62ad0646
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6372845
Commit-Queue: Sam Goto <goto@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1435577}
Update trusted signals KVv2 request helper to take optional
perBuyerTKVSignals and sellerTKVSignals, create a new perPartitionMetadata field on top level of the request, and add
the signals into new contextualData field in perPartitionMetadata.
Bug: 391727084
Change-Id: I7b4ec8642bd09a10ed0e6b473f034072a55d249a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6316991
Reviewed-by: mmenke <mmenke@chromium.org>
Commit-Queue: Tianyang Xu <xtlsheep@google.com>
Cr-Commit-Position: refs/heads/main@{#1435469}
Apple tvOS only supports single-process applications. Therefore,
this CL removes the content, GPU, and network process bundle
dependencies from the content_shell bundle.
Additionally, this CL uses target_platform == "iphoneos" for
improved readability.
Bug: 391914246
Change-Id: Ieee05d20dc85d2f9471163280a6290221526c5b2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6367806
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Gyuyoung Kim <gyuyoung@igalia.com>
Cr-Commit-Position: refs/heads/main@{#1435445}
We add an additional counter to the shared memory to track whether all
sync calls have made it to the network service. If there are still
pending writes to be committed, then Cookies() issues an IPC.
Bug: 380864710
Change-Id: Ib1eb97e1475e1efd6977c1cfa07273d5b89d0e8e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6373304
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Aldo Culquicondor <acondor@chromium.org>
Reviewed-by: Kenichi Ishibashi <bashi@chromium.org>
Reviewed-by: Oksana Zhuravlova <oksamyt@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1435404}
This is a reland of commit 8f7e0bcec0,
except for the actual change to build/write_buildflag_header.py
Original change's description:
> build: Be stricter about buildflag values
>
> We don't want buildflag headers to contain arbitrary expressions
>
> A recent change had used
>
> "ENABLE_FOO=$enable_foo_1 || $enable_foo_2",
>
> which `gn` turned into `true || false`, which write_buildflag_header.py
> wrote to a generated header verbatim. Checking
>
> #if BUILDFLAG(ENABLE_FOO)
>
> would then expand to
>
> #if true || false
>
> but `true` and `false` are only valid in C++, not C.
>
> (...and buildflag headers get included in resource scripts, and
> rc.exe preprocesses using C semantics, not C++ semantics, and hence
> silently does the wrong thing.)
>
> So only allow `true` and `false` (which buildflag_headers.py maps
> to 1 and 0 in its output), and string literals, for things like
> ALTERNATE_CDM_STORAGE_ID_KEY. We could also consider (re)allowing
> int literals, but those silently evaluate to truthy or falsy values
> in preprocessor expressions -- several places were checking
> `#if BUILDFLAG(CHROME_PGO)` when they morally mean
> `#if BUILDFLAG(CHROME_PGO) == 1`. Since we currently have no use
> cases for arbitrary int values in buildflags, disallow them.
> String literals don't have this problem.
>
> The main motivation is to block things like `true && false` and
> `false || true`.
>
> (Convert all `=1` / `=0` to `=true` / `=false` to make this work.
> We must support `true` and `false` for the very common
> `FOO=$foo` use case.)
>
> The CHROME_PGO issue above is fine since we also checked
> BUILDFLAG(CLANG_PROFILING_INSIDE_SANDBOX) at the same time, and
> that's only set in the profiling phase, but it's still confusing.
> So use two boolean build flags for CHROME_PGO instead. (No behavior
> change.)
>
> Bug: 403123830
> Change-Id: I7a6cedf063824b280f1fe03a07586cf77f649b29
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6371822
> Commit-Queue: Nico Weber <thakis@chromium.org>
> Owners-Override: Nico Weber <thakis@chromium.org>
> Reviewed-by: Hans Wennborg <hans@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1435044}
Bug: 403123830
Change-Id: I2dcea00d45405783848d089ce37d52b0294a7189
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6372328
Reviewed-by: Hans Wennborg <hans@chromium.org>
Owners-Override: Nico Weber <thakis@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Auto-Submit: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1435395}
Similar to OCR client type, add main content extractor client type.
This addition makes it easier to distinguish between usage, failure, and
bugs for different clients of this service and centeralize metrics
collection.
AX-Relnotes: n/a
Bug: 359853518
Change-Id: I29403795f80a77c8899f26ad09d63036101653b5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6368519
Reviewed-by: Alex Gough <ajgo@chromium.org>
Reviewed-by: CJ Huang <chenjih@google.com>
Commit-Queue: Ramin Halavati <rhalavati@chromium.org>
Reviewed-by: Mark Schillaci <mschillaci@google.com>
Cr-Commit-Position: refs/heads/main@{#1435250}
Initial work for adding new feature that support Contextual Data for TKV
servers:
1. Create a new runtime enabled flag FledgeTrustedSignalsKVv2ContextualData.
2. Add a new field "perBuyerTKVSignals" in auction config.
Bug: 391727084
Change-Id: Ib03a5f8b7a40f34cfc6a415c76ef0bb61c473d06
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6191235
Commit-Queue: Tianyang Xu <xtlsheep@google.com>
Reviewed-by: Caleb Raitto <caraitto@chromium.org>
Reviewed-by: Joe Mason <joenotcharles@google.com>
Reviewed-by: Domenic Denicola <domenic@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1435118}
Typically RenderWidgetHostImpl::SynchronizeVisualProperties throttles
itself, as Renderer layout is expensive. However when we are hidden the
Renderer will not submit new frames, so the Ack will never arrive.
Historically we unthrottle when we hide.
However there are now ways in which Linux can perform size changes on
the hidden window. Which is triggering a synchronization and throttling
after the hide.
EvictionThrottlesDraw was added to prevent Renderers from submitting
content to invalid Surfaces. On Linux the minimization of a window
will unlock the visible tab, allowing for it to be evicted.
The hidden synchronization was throttling future updates, so when we
were becoming visible again we would have no content to display.
This updated RenderWidgetHostImpl::WasShown to unthrottle
synchronization if it is evicted. So that the Renderer always has the
new surface to submit against.
Bug: 381224161
Change-Id: Icee650235cbc7369aa0633dd758a0ea9f1017faf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6374129
Commit-Queue: Jonathan Ross <jonross@chromium.org>
Reviewed-by: Kramer Ge <fangzhoug@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1435114}
Prior to this CL, popping up a new window involved two renderer->browser
IPC's: CreateNewWindow(), which is sync; and ShowCreatedWindow(), which
is not sync. In addition to the linked bug, this arrangement requires
some awkward architecture in the window-creating code.
This CL combines the two IPC's into a single sync IPC. There are a few
failure scenarios that currently prevent ShowCreatedWindow() from
running after CreateNewWindow(); but those failure conditions are known
to the browser at the time the reply to CreateNewWindow() is sent, so
the browser code can act accordingly.
The new behavior is behind an enabled-by-default feature flag, to give
it an easy kill switch in case of breakage.
Bug: chromium:41099297
Change-Id: I0c67de461d0f646085e13cab25114cfe1b150139
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6343761
Reviewed-by: David Trainor <dtrainor@chromium.org>
Commit-Queue: Stefan Zager <szager@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1435113}
This reverts commit 8f7e0bcec0.
Reason for revert: Broke the tree. https://ci.chromium.org/ui/p/chromium/builders/ci/linux-cast-x64-rel/11722/overview
Original change's description:
> build: Be stricter about buildflag values
>
> We don't want buildflag headers to contain arbitrary expressions
>
> A recent change had used
>
> "ENABLE_FOO=$enable_foo_1 || $enable_foo_2",
>
> which `gn` turned into `true || false`, which write_buildflag_header.py
> wrote to a generated header verbatim. Checking
>
> #if BUILDFLAG(ENABLE_FOO)
>
> would then expand to
>
> #if true || false
>
> but `true` and `false` are only valid in C++, not C.
>
> (...and buildflag headers get included in resource scripts, and
> rc.exe preprocesses using C semantics, not C++ semantics, and hence
> silently does the wrong thing.)
>
> So only allow `true` and `false` (which buildflag_headers.py maps
> to 1 and 0 in its output), and string literals, for things like
> ALTERNATE_CDM_STORAGE_ID_KEY. We could also consider (re)allowing
> int literals, but those silently evaluate to truthy or falsy values
> in preprocessor expressions -- several places were checking
> `#if BUILDFLAG(CHROME_PGO)` when they morally mean
> `#if BUILDFLAG(CHROME_PGO) == 1`. Since we currently have no use
> cases for arbitrary int values in buildflags, disallow them.
> String literals don't have this problem.
>
> The main motivation is to block things like `true && false` and
> `false || true`.
>
> (Convert all `=1` / `=0` to `=true` / `=false` to make this work.
> We must support `true` and `false` for the very common
> `FOO=$foo` use case.)
>
> The CHROME_PGO issue above is fine since we also checked
> BUILDFLAG(CLANG_PROFILING_INSIDE_SANDBOX) at the same time, and
> that's only set in the profiling phase, but it's still confusing.
> So use two boolean build flags for CHROME_PGO instead. (No behavior
> change.)
>
> Bug: 403123830
> Change-Id: I7a6cedf063824b280f1fe03a07586cf77f649b29
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6371822
> Commit-Queue: Nico Weber <thakis@chromium.org>
> Owners-Override: Nico Weber <thakis@chromium.org>
> Reviewed-by: Hans Wennborg <hans@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1435044}
Bug: 403123830
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: I5ab67b3e6ae54e9642f2402449823146c4e45aab
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6373873
Commit-Queue: Lei Zhang <thestig@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Owners-Override: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1435052}
We don't want buildflag headers to contain arbitrary expressions
A recent change had used
"ENABLE_FOO=$enable_foo_1 || $enable_foo_2",
which `gn` turned into `true || false`, which write_buildflag_header.py
wrote to a generated header verbatim. Checking
#if BUILDFLAG(ENABLE_FOO)
would then expand to
#if true || false
but `true` and `false` are only valid in C++, not C.
(...and buildflag headers get included in resource scripts, and
rc.exe preprocesses using C semantics, not C++ semantics, and hence
silently does the wrong thing.)
So only allow `true` and `false` (which buildflag_headers.py maps
to 1 and 0 in its output), and string literals, for things like
ALTERNATE_CDM_STORAGE_ID_KEY. We could also consider (re)allowing
int literals, but those silently evaluate to truthy or falsy values
in preprocessor expressions -- several places were checking
`#if BUILDFLAG(CHROME_PGO)` when they morally mean
`#if BUILDFLAG(CHROME_PGO) == 1`. Since we currently have no use
cases for arbitrary int values in buildflags, disallow them.
String literals don't have this problem.
The main motivation is to block things like `true && false` and
`false || true`.
(Convert all `=1` / `=0` to `=true` / `=false` to make this work.
We must support `true` and `false` for the very common
`FOO=$foo` use case.)
The CHROME_PGO issue above is fine since we also checked
BUILDFLAG(CLANG_PROFILING_INSIDE_SANDBOX) at the same time, and
that's only set in the profiling phase, but it's still confusing.
So use two boolean build flags for CHROME_PGO instead. (No behavior
change.)
Bug: 403123830
Change-Id: I7a6cedf063824b280f1fe03a07586cf77f649b29
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6371822
Commit-Queue: Nico Weber <thakis@chromium.org>
Owners-Override: Nico Weber <thakis@chromium.org>
Reviewed-by: Hans Wennborg <hans@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1435044}
This change removes usages of StorageType in QuotaClient methods.
After StorageType::kSyncable deprecation, all other storage types
except kTemporary are deprecated. So we no longer need to specify
StorageType. Data that was previously associated with kSyncable
is now part of kTemporary.
Main part of this change is in quota_client.mojom and updates
all overrides and callers of impacted methods.
Bug: 40211051
Change-Id: I000a457346dd1e383c6252dfa22c75cfd3c6e721
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6368800
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Ayu Ishii <ayui@chromium.org>
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1435031}
This cl adds devtools instrumentation calls that associate KVv2 trusted
signals cache fetches with their corresponding devtools auction IDs.
Currently, if a new auction is associated with a fetch after it has
been sent over the network, nothing is logged though that may be worth
changing in a followup.
Other corner cases:
* If an auction is cancelled before a fetch starts, but the fetch is
still started due to other ongoing auctions, the fetch will still log
an event associated with the failed auction. Changing this behavior
would require substantial complexity and/or more copies of devtools
IDs, so may not be worth it. Devtools consumers are supposed to be
robust against such things, anyways.
* If an entry from the cache is used directly, without triggering
a fetch, nothing is logged to devtools. The fetch events require
a network request ID, but the network request may have finished long
ago (and in the future, may also have been in another tab). We may
want to log some other event in this case, but that's an issue for
another day.
Bug: 379843989
Change-Id: I322218ee8fd8018b6011b55854f61349802407ec
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6367483
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Commit-Queue: mmenke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1435010}
Windows sandbox restrictions cause DirectReceiver's ThreadLocalNode to
crash in Transport::CreatePair. As a workaround create a transport for
the thread that's expected to use DirectReceiver before the sandbox
is locked down (which is still in single threaded context), and pass
it to ThreadLocalNode when it's assigned to the thread.
Bug: 40266729
Change-Id: Ic881eac9cf570d023a362b2cfc12f8234d706eb5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6332336
Reviewed-by: Alex Gough <ajgo@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Joe Mason <joenotcharles@google.com>
Cr-Commit-Position: refs/heads/main@{#1434954}
Base gfx::NativeView and gfx::NativeWindow on weak owned base types,
removing some double-declaration in ui/gfx/native_widget_types.h.
This makes things only slightly less awful, but less awful
nonetheless.
Bug: 40264240
Change-Id: I98c1a5a125cf26bf1d4759c834f965295358af3c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6361987
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Reviewed-by: Dana Fried <dfried@chromium.org>
Reviewed-by: ccameron chromium <ccameron@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Reviewed-by: Martin Kreichgauer <martinkr@google.com>
Cr-Commit-Position: refs/heads/main@{#1434944}
When https://crbug.com/404294118 was reverted, a comment was left in
the code noting the conditions for which a re-land would be possible.
After the revert, a second regression was reported, so update the
code comment with a pointer on the issue, so that it can be avoided
when the re-land happens.
Bug: 389067059
Bug: 404294118
Change-Id: I895e6cae81bd36115858efbd32e5648c710d6289
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6373059
Reviewed-by: Jayson Adams <shrike@chromium.org>
Commit-Queue: Jayson Adams <shrike@chromium.org>
Auto-Submit: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1434861}
Before this CL, if a page redirected to itself and accessed a cookie
outside a navigation (document.cookie = 'foo=bar'), we would sometimes
attribute that access to a redirect with the same URL.
This CL uses the source of the cookie access to avoid this.
Change-Id: I3c99784adc9aefed7f519ef964f1a30b5b7e7349
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6352717
Reviewed-by: Andrew Liu <liu@chromium.org>
Reviewed-by: Svend Larsen <svend@chromium.org>
Commit-Queue: Giovanni Ortuno Urquidi <ortuno@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1434859}
Populate this with the `virtualViewId` which originates from
ui/accessibility/platform/ax_unique_id.h
a globally unique id meant for use across node updates.
Change-Id: I3478025ceba816df138c937f3e76835bc4131599
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6370662
Commit-Queue: David Tseng <dtseng@chromium.org>
Reviewed-by: Wenyu Zhang <zhangwenyu@google.com>
Cr-Commit-Position: refs/heads/main@{#1434854}
The current parsing drops info about the aliases, instead flattening
them into the set itself and treating them as if they were provided as
separate, "normal" entries.
Preserving more of the structure of the enterprise policy allows the RWS
implementation to layer FirstPartySetsContextConfigs in arbitrary orders
and respect the alias structure correctly.
Change-Id: I40ceffe1767f4ae38a8ff7987220065f3c6999b2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6368034
Reviewed-by: Sam LeDoux <sledoux@chromium.org>
Commit-Queue: Sam LeDoux <sledoux@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1434825}
When there is an origin mismatch for close/resolve, we currently
fail silently. This adds a console message for this case.
Bug: 400996797
Change-Id: I3f588ced60ceffcff115cbafb95300a6194a42d2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6343495
Commit-Queue: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: Nicolás Peña <npm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1434807}
AXSystemCaretWinTest
Remove the AccessibilityEventsCaretHide test from the dump
accessibility event test suite and re-enable the TestCaretMSAAEvents
test. Browser test failures are occurring because the show and hide
caret events are being lost when multiple tests run in parallel and
focus changes. This happens as the events are sometimes missed due to
overlapping test executions. To prevent this, interactive tests run
serially to ensure they do not interfere with each other.
There is already an existing test that covers the same caret
functionality, but it was previously disabled due to flakiness on
Windows 7. This flakiness is no longer observed after enabling the
test again.
Bug: 41417070,40820766
Change-Id: I3ece54983ce2d249b69c19d0c8d66111d151ccc3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6315564
Reviewed-by: Greg Thompson <grt@chromium.org>
Commit-Queue: Sejal Anand <sejalanand@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1434794}
Explicitly disable LNA feature on some Private Network Access (PNA)
tests. LNA is going to replace PNA, but needs to co-exist in the code
base until M137 (because of enterprise features).
Bug: 395895368
Change-Id: Id1506dab4d55288110ed7bf5a2900a58d1b35e83
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6357033
Reviewed-by: Camille Lamy <clamy@chromium.org>
Commit-Queue: Hubert Chao <hchao@chromium.org>
Reviewed-by: Nick Harper <nharper@chromium.org>
Reviewed-by: Chris Thompson <cthomp@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1434775}
This CL modifies input::FlingController so that, if
ui::HostBeginFrameObserver coalesces multiple frames,
input::FlingController will use the begin frame timestamp of the first
coalesced frame as the generation timestamp of the inertial (fling)
scroll update.
This addresses a potential source of scroll jank undercounting in
situations where the browser emits no inertial (fling) scroll updates
(even though it should emit them) because the browser is busy.
The change is gated behind a new feature,
UseFirstCoalescedFrameAsFlingGenerationTimestamp, so that we could
evaluate its impact via Finch.
Bug: 404464598
Change-Id: I73171c79f8555e40847f71b77b29c9272a97abe2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6367434
Reviewed-by: Victor Miura <vmiura@chromium.org>
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Commit-Queue: Petr Cermak <petrcermak@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1434684}
This reverts commit 8c794f38d3.
Reason for revert: breaks test on multiple Mac bots crbug.com/404576872
Original change's description:
> [A11yPerformance] Clean up BrowserAccessibilityState
>
> 1. Clarify which methods/variables are related to Auto Disable as
> opposed to just Disable (manually disabling of a11y), so that
> it's no longer confusing what belongs to what intention.
>
> 2. Rename some methods to accurately reflect what they do,
> and add comments:
> * IsRendererAccessibilityEnabled() -> IsAccessibilityAllowed().
> This was not specific to renderers, or whether a11y was enabled.
> It returned true if a11y was not disallowed via the command line.
> * EnableAccessibility() -> EnableCompleteAccessibility().
> This turns on kAXModeComplete.
>
> 3. Remove some poorly named and redundant methods that are not
> actually needed:
> * ResetAccessibilityMode() -- the same as DisableAccessibility().
> * OnScreenReaderDetected() -- did not actually reflect screen
> reader detection and was just a way to EnableAccessibility(), so
> is redundant with that. Any remaining methods and modes with
> "screen reader" in the name will now make sense.
> * OnScreenReaderStopped() -- did not actually reflect the stoppage
> of a screen reader and callers are better off using
> DisableAccessibility().
>
> 4. The new UMA Accessibility.EngineUse.TimeUntilStart that was just
> added was not working on all platforms, because some platforms
> use AddAccessibilityModeFlags() and others use
> EnableAccessibility(). Move the UMA code to
> OnAccessibilityAPIUsage() where it will always be hit.
>
> This relates to a11y performance because it helps build the
> foundation for the auto disable refresh by clarifying what
> different pieces do and cleaning up code paths.
>
> Follow-ups:
> - Audit calls to OnAccessibilityAPIUsed(), such as from
> AXPlatformNodeDelegate::GetRole(). If we don't change that, we'll
> always think that there's new API usage every time we Unserialize
> from a renderer, which breaks the auto-disable heuristic.
> - Use ScopedAccessibilityMode for chrome/browser/apps/app_shim/app_shim_host_mac.cc.
>
> Bug: 401232343
> Change-Id: Id386c378812484aae01e2a93dac90336c0aa7ae3
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6333854
> Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
> Reviewed-by: Greg Thompson <grt@chromium.org>
> Reviewed-by: Benjamin Beaudry <benjamin.beaudry@microsoft.com>
> Reviewed-by: Nasko Oskov <nasko@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1434483}
Bug: 401232343,404576872
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: I6d43b0fa9d36b7ee0adeaf38b2b04e2b044eea60
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6367795
Reviewed-by: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Takuto Ikuta <tikuta@chromium.org>
Commit-Queue: Ming-Ying Chung <mych@chromium.org>
Owners-Override: Ming-Ying Chung <mych@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1434613}
After a lot of investigation, it's still not clear how to trigger this,
because it seems to require storing a File in IndexedDB that has unknown
size and/or modification date. I have not been able to construct such a
file without running into other errors that would prevent storing and
reading the file.
Bug: 393395443
Change-Id: I9b5eb531bb7c9e1338fdd70a6a16e578ef43d668
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6368285
Reviewed-by: Steve Becker <stevebe@microsoft.com>
Commit-Queue: Evan Stade <evanstade@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1434606}
This is to fix the issue that Apple intelligence's writing tools grabs
the focus from browser after the user click replace button in writing
tools bubble which causes the replaced text can not be inserted into
browser IME since the content's NSView loses focus. Please note that
this is a workaround fix and should be removed after the issue is
finally fixed by Apple which is tracked via FB16872510.
Bug: 385170286
Change-Id: Ied94e2c3eba320cfeeb1eea68f6a5527e6ccd6ba
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6320619
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Leon Han <shulianghan@microsoft.com>
Commit-Queue: Fei Chen <feich@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1434585}
If prefetch(es) are already failed, removing browsing data to clear
prefetches will also try to update the PrefetchStatus for all
prefetches. This causes a crash as StatusUpdateIsPossibleAfterFailure
was set to False for EvictAfterBrowsingDataRemoved. This CL changes it
to True.
Bug: 404497392, 404473006
Change-Id: I8d8cf1fe3b31016ba2297ca670fb1c6ff5132736
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6365822
Commit-Queue: Steven Wei <stevenwei@microsoft.com>
Reviewed-by: Ken Okada <kenoss@chromium.org>
Reviewed-by: Taiyo Mizuhashi <taiyo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1434584}
