To clarify what actually happens, add more CHECK to see if the
assumption is correct.
Also this patch converts existing DCHECKs with CHECKs to follow
the up-to-date guideline and to have strict checks to help
investigation.
Bug: 1394486
Change-Id: Icc2a7158483832afade6eb67cf2ad367d7acaf11
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4584269
Commit-Queue: Hiroki Nakagawa <nhiroki@chromium.org>
Auto-Submit: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152884}
This is a high priority change, the bug this fixes is stopping
all JAWS 2021 users from being able to access web contents.
With some Windows 11 features causing kNativeAPIs to be
turned on after startup, our honeypot code was no longer
being triggered. Since there are many other ways to turn
on accessibility this was not noticed until recently.
This change updates our logic to no longer consider the
fact that some accessibility has been enabled as an
indication that we no longer should fire the honey pot
event.
With this change we will continue to send honey pot events
until web contents accessibility has been turned on. The
honey pot will trigger web contents accessibility, and at
that point will no longer fire.
Bug: 1450993
Change-Id: I65cfa0e2c5daf2eaef19241e70e1f23670714216
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4585299
Reviewed-by: Benjamin Beaudry <benjamin.beaudry@microsoft.com>
Reviewed-by: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152873}
This CL add WebSerial into `WebSchedulerTrackedFeature` and create
scheduling affecting feature handle when a SerialPort is activated. By
doing so a hidden page won't be intensively throttled when holding a
opened SerialPort.
Change-Id: I2343e663aa34d80a5c51a1dd79542536c6b0f739
Bug: 1442957
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4545501
Commit-Queue: Alvin Ji <alvinji@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152871}
Reporting beacons can be triggered by fenced frames and asynchronously
sent through FencedFrameReporter. This CL makes DevTools aware of these
requests.
Currently, FencedFrameReporter should only exist when the fenced frame
exists, but this may not always be the case (e.g., if we want to
prevent beacons from being lost due to races). To make DevTools
integration future-proof, we store the initiator's frame tree node id
and then retrieve the frame tree node asynchronously, when the request
starts. If the frame tree node doesn't exist at that point, we skip
registering the request with DevTools. This means the support is only
best-effort but always safe.
Bug: 1424853
Change-Id: Id4380464f43ad35f65d611457516051ff5e65527
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4395189
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Commit-Queue: Garrett Tanzer <gtanzer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152810}
The succeed_with_console_message parameter from MockConfiguration is not
needed because we can just check the console error messages directly. It
is also not in the right struct anyways since it is really an
expectation, not part of the config.
Change-Id: I83e945bb3cef93fc7c76e3efa5f5199e574ce711
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4582837
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152758}
Given null reports generation(https://github.com/WICG/attribution-reporting-api/pull/750), it is possible that multiple reports are
created from a single trigger.
To avoid leaking which reports are null reports and which ones are real
, we request multiple verification tokens that are then randomly
assigned to generated reports.
This CL, update the Report Verification feature to request the reporting
origin to sign multiple tokens by sending for signature a list
structured header that contains N blinded messages.
BorringSSL currently does not support batch issuance with different
messages. As a result, we instantiate N BorringSSL cryptographers and
begin N issuance per trigger.
Bug: 1435014,1440838,1440744
Change-Id: I92cb0b729c270414732985cf5776af748c5fa1a5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4482909
Reviewed-by: Ian Vollick <vollick@chromium.org>
Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Commit-Queue: Anthony Garant <anthonygarant@chromium.org>
Reviewed-by: Nan Lin <linnan@chromium.org>
Reviewed-by: Kenichi Ishibashi <bashi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152707}
This CL adds a couple of console error messages for when:
* The loginHint filter results in no accounts being displayed
* getUserInfo() fails
Bug: 1440181
Change-Id: I7ebdb1654b2d5ac884be1fe1860d42dfbe2ae4d6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4582603
Reviewed-by: Yi Gu <yigu@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152700}
This CL addresses a bug where the bounding rects for the menu list
options where being set incorrectly when they were found inside
of an iframe. We were not taking into account the distance from the
current frame to the parent frame.
This CL makes it so we offset correctly taking this into account, even
in the scenario where we could be nested into multiple iframes.
Change-Id: I0d33d2301025412e6019e5483437fc8a1eee1d80
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4547691
Reviewed-by: Mason Freed <masonf@chromium.org>
Reviewed-by: Kurt Catti-Schmidt <kschmi@microsoft.com>
Commit-Queue: Javier Contreras <javiercon@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1152682}
- Remove job_policy_ambient_mark_vmo_exec from all component
manifests.
- Remove most usage of the ambient-VMEX-capable ELF test runner.
Some use of the ambient-VMEX ELF runner remains, to support tests
which run SwiftShader in-process, which requires ambient-VMEX for its
shader JIT.
The test CML fragment for the VMEX-capable ELF test runner is also
still required by out-of-tree dependencies, notably ANGLE.
Bug: 1290907, 1185811, 1022542
Change-Id: I9e27afa869eaffb740f3501a972cafbc179346a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4566483
Reviewed-by: David Dorwin <ddorwin@chromium.org>
Auto-Submit: Wez <wez@chromium.org>
Quick-Run: Wez <wez@chromium.org>
Commit-Queue: Wez <wez@chromium.org>
Owners-Override: Wez <wez@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152660}
Adds WebGL 1 and 2 test runtimes for Android, Linux, Mac, and Windows
and uses them on the relevant platforms instead of only using Linux
data. In the event that WebGL tests are run on another platform such as
ChromeOS, they will default to using the Linux timings like before.
This should give us better sharding performance since test runtimes can
vary depending on platform.
Data was retrieved from:
Android FYI Release (Pixel 4)
webgl_conformance_gles_passthrough_tests
webgl2_conformance_gles_passthrough_tests
Linux FYI Release (NVIDIA)
webgl_conformance_gl_passthrough_tests
webgl2_conformance_gl_passthrough_tests
Mac FYI Retina Release (AMD)
webgl_conformance_gl_passthrough_tests
webgl2_conformance_gl_passthrough_tests
Win10 FYI x64 Release (NVIDIA)
webgl_conformance_d3d11_passthrough_tests
webgl2_conformance_d3d11_passthrough_tests
Bug: 1448636, 1450353, 1450355
Change-Id: I696b1ab924705a6b8555db6a58c28d954d653f99
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4576029
Auto-Submit: Brian Sheedy <bsheedy@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Commit-Queue: Brian Sheedy <bsheedy@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152623}
The CHECK in UnsetSpeculativeRenderFrameHost() mistakenly also triggers
when the current RFH has a pending commit navigation, which should not
be a problem, so this updates it to only check the speculative RFH.
This also updates the CHECK in ResetOwnedNavigationRequests to be
consistent.
Bug: 1450036, 1450531
Change-Id: I659c5ce90fd6253f03f1742e103af21c7e4c443c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4583916
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Auto-Submit: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152613}
This patch is concerned with updating the blink::Page browsing context
group when a cross browsing context group navigation takes place. This
can take two forms:
- When a local frame navigates, the BrowsingContextGroupInfo is passed
directly to the CommitNavigationParams, for an immediate update.
- When a remote frame navigates in another process, the renderer gets
updated by a message from the PageBroadcast interface. This incurs an
inevitable small delay.
DETAILS
For the local frame update, the passed BrowsingContextGroupInfo is optional and is only set for top-level navigations to a different
browsing context group. It takes the following route:
- RenderFrameImpl::CommitNavigation
- WebLocalFrameImpl::CommitNavigation
- FrameLoader::CommitNavigation
- DocumentLoader::DocumentLoader
- DocumentLoader::CommitNavigation
- Page::UpdateBrowsingContextGroup
When the browser receives the information that a page has navigated to
another browsing context group, we use the PageBroadcast interface to
tell each renderer process holding a proxy of the navigated frame, that
the blink::Page is now in another browsing context group. This goes
through:
- Navigator::DidNavigate
- RenderFrameHostManager::ExecutePageBroadcastMethod
- WebViewImpl::UpdatePageBrowsingContextGroup
- Page::UpdateBrowsingContextGroup
Testing is done in the next patch with the
CoopRestrictPropertiesAccessBrowserTest suite.
Bug: 1221127
Change-Id: Ie6300caee1c3b3e92add97a002416c8e5eddf316
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4514696
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152564}
Previously, the AX tree dump would only output the names of any ATK
relations on a node. This means we couldn't make assertions on the
targets a relation needs to point to - for example, we might want to
assert that a relation points to a specific number of targets.
Now, we will output the roles of any nodes that an ATK relation
points to. We will also update existing tests accordingly.
Change-Id: I18985e2934f254575b6a6255c63f2173f6b264f7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4568917
Commit-Queue: Joanmarie Diggs <jdiggs@igalia.com>
Reviewed-by: Joanmarie Diggs <jdiggs@igalia.com>
Cr-Commit-Position: refs/heads/main@{#1152517}
This CL adds the following UMA metrics for getUserInfo:
* Time between request received in the browser and completed
* Number of accounts returned by the API (zero, one, or multiple)
Bug: 1440181
Change-Id: Idb30a82c57d0416559b97fd01c9817f1e590355e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4582188
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: Yi Gu <yigu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152503}
Currently, users can double tap to select a word in an editable
environment. This CL allows users to expand the selection after a
double press by directly dragging after the second tap down (without
lifting after the tap down). This is similar to existing long press
drag behaviour, but initiated by a double press instead of a long press.
Summary of approach:
1. Add a tap_down_count property to kGestureTapDown events.
2. In blink::GestureManager, add selection behaviour to
HandleGestureTapDown if the tap down has tap_down_count > 1.
(Previously, the selection behaviour only occurred on the tap event.)
3. Re-use the existing LongPressDragSelector by allowing drag selection
to be initiated by a double press as well as a long press.
Doc with summary of the feature, approach and considerations:
https://docs.google.com/document/d/1kZeGeGXkBlNsIRVLs27YWuOEVqfn4IH1U1sxmqZ5QYU/edit?usp=sharing&resourcekey=0-I-9oPhncwGvKJeSMRe7kTA
WIP design doc for overall feature (see "Double Press and Drag"
sections. Note that this is primarily planned for CrOS but may also be
enabled for other platforms eventually):
go/cros-touch-text-editing#heading=h.tlmeepz7ip57
Bug: b:244116654, b:264824689
Change-Id: Id6cbc3b687c7c26549b33d86a2d5194bc3ffd910
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4297101
Reviewed-by: Robert Flack <flackr@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Michelle Chen <michellegc@google.com>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Sam McNally <sammc@chromium.org>
Reviewed-by: Mustaq Ahmed <mustaq@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152437}
This test confirms that the ordering of history navigations stay the
same, and we end up at the same history entry regardless of whether
navigation queueing is enabled or not.
Bug: 1220337
Change-Id: Iaadbb3837bf75a4fd991a17b5797cbfa461d1bac
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4569406
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Auto-Submit: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152430}
Previously, prerendering pages cannot create blob URLs, as this API
uses a sync IPC to communicate, and we would cancel prerendering by
default in this case to ensure prerendering is safe.
After auditing it (see reasoning), we think creating an object URL seems
safe, and we can grant it during prerendering.
Reasoning:
- The blob url should be same-origin as the prerendering origin, so we
do not touch other origins.
- The security concerns should be addressed by this API.
https://w3c.github.io/FileAPI/#security-discussion
Bug: 1406125
Change-Id: I3c94e45fe59adb7227a71a702a4793ee8281b395
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4583910
Commit-Queue: Lingqi Chi <lingqi@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152423}
This is a refactoring CL that removes
`blink::mojom::ServiceWorkerFetchHandlerBypassOption
fetch_handler_bypass_option` from
CreateServiceWorkerSubresourceLoaderFactory. The param was introduced in
the previous CL [1], but it was unnecessary plumbing, we can pass
`mojom::blink::ServiceWorkerFetchHandlerBypassOption::kDefault` directly
to ControllerServiceWorkerConnector in
RendererBlinkPlatformImpl::CreateServiceWorkerSubresourceLoaderFactory.
[1] crrev.com/c/4451966
Bug: 1420517
Change-Id: Ifd4d3867b2b0c7f0e00d27b342255287b0a1c017
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4573500
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Shunya Shishido <sisidovski@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152364}
With RenderDocument, cross-document navigations will use new
RenderFrameHosts (and RenderViewHosts, RenderWidgetHosts, etc for
main frame navigations). This CL updates some WebUI tests that didn't
expect those changes.
Bug: 936696
Change-Id: I9a43d164dedf836ef71f0e30d8de0b4d0a99fe8c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4574239
Reviewed-by: Giovanni Ortuno Urquidi <ortuno@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152342}
With RenderDocument, cross-document navigations will use new
RenderFrameHosts (and RenderViewHosts, RenderWidgetHosts, etc for
main frame navigations). This CL updates a test that didn't expect
those changes.
Bug: 936696
Change-Id: Icbd1ca21946a8e1470b4cb4dc402ed0a880475c0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4578344
Reviewed-by: John Delaney <johnidel@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152323}
A StringPiece is a pointer/length pair and not guaranteed to be
NUL-terminated. Passing .data() into a function that expects a
NUL-terminated const char * is invalid and will go out-of-bounds
(security bug) if the StringPiece didn't happen to created from a
NUL-terminated value.
Fortunately, most StringPieces are created from buffers that happen to
be NUL-terminated, but we cannot safely rely on this. This fixes a
bunch of instances I found looking through code search, most of it in
ash. Some observations:
- Some code converts StringPiece to string by calling .data(). This is
unnecessary because there is already a conversion defined.
- StringPrintf does not work well with StringPiece. I converted to
string or used StrCat.
- When functions take const std::string& and the caller has a
StringPiece, it is a common mistake to call .data(). This is
incorrect, but. To reduce the risk of people making that mistake
again, I converted a few functions to StringPiece where it was easy.
Change-Id: I9978c11adbc6f36acf0401e765e4495bdbe8c470
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4573916
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: David Benjamin <davidben@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152307}
Changes the test interface implementations of WebUIJSBridge unittests
to match how real WebUI interfaces are implemented i.e. WebUI interfaces
are created when they are bound or stored in a global object like
BrowserContext.
WebUIJSBridges and WebUIControllers have a 1:1 relationship. So it also
changes test_webui_js_bridge2's WebUIController from TestWebUIJsBridgeUI
to TestWebUIJsBridgeUI2.
Bug: 1407936
Change-Id: If8031782bc90645eb4487f3c3af36ada60e0f0ba
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4578938
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Giovanni Ortuno Urquidi <ortuno@chromium.org>
Reviewed-by: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/main@{#1152281}
Previously each renderer on Android would check for key system support
by using cdm::QueryKeySystemSupport(), which uses the old IPC protocol.
New way is to use the KeySystemSupport mojo interface where key
systems are registered in the browser, and renderers subscribe to
notifications. This matches what is being done for desktop browsers
(and Chrome on Android).
KeySystemSupport allows for delayed determination of what features are
supported until the first time it is queried. So registration in the
browser is done without specifying any capabilities, and they will be
computed the first time they are needed.
This also moves AddOtherAndroidKeySystems() into a separate file so
that it can be reused for this change.
Tested using WebView Browser Tester and playing videos from Widevine's
integration site on a Pixel 4 and again on an Android emulator.
Bug: 853336
Test: see above
Change-Id: Ida12361fa8367f9644287d4ef95eb6a723034ab7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4368876
Reviewed-by: Xiaohan Wang <xhwang@chromium.org>
Commit-Queue: John Rummell <jrummell@chromium.org>
Reviewed-by: Nate Fischer <ntfschr@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152237}
This cl reenables manual occlusion detection for < macOS 13.0 and
>= macOS 13.3. It also combines the previous two experiments
(occlusion detection and display sleep) into a single experiment
that combines both features, per a previous review with Catan.
Test: out/Default/content_browsertests \
--gtest_filter=*WindowOcclusionBrowser*
Bug: 883031
Change-Id: I2c5a4de21bb64406fa53bff7a7644df6671b7188
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4529204
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Commit-Queue: Jayson Adams <shrike@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152207}
This CL continues the AccessibilityState consolidation work for Clank.
With this CL we remove the hard dependency on AccessibilityManager that
the WebContentsAccessibilityImpl class has. We will instead use the new
AccessibilityState class directly. We also remove the corresponding
*ForTesting method and make callers of it use AccessibilityState as
well. This is cleaner as the web contents should not be used to control
the state of accessibility of the entire app.
AX-Relnotes: N/A
Bug: 1430202, b/265493191
Change-Id: Ib2c4285fde919fa985902204ead25364d9215bf4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4569293
Reviewed-by: Amanda Lin Dietz <aldietz@google.com>
Reviewed-by: Bo Liu <boliu@chromium.org>
Commit-Queue: Mark Schillaci <mschillaci@google.com>
Reviewed-by: Theresa Sullivan <twellington@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152206}
Since kNetworkServiceInProcess flag doesn't imply
IsInProcessNetworkService directly due to some environment
restriction, add new function to force that.
This CL also moves the flag check in the tests from SetUp() to
SetUpOnMainThread() because t/v/fieldtrial_testing_config.json applies
flags at content::ShellContentBrowserClient::SetUpFieldTrials(), which
is called after SetUp().
Bug: 1395707
Change-Id: Ice6205294e6633c03da927be5e15da2ca4216023
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4520651
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Auto-Submit: Yoichi Osato <yoichio@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Owners-Override: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152173}
I was able to add tests that verifies the latest RRF functionality
without adding any new interfaces or observers. Instead I could use
the HistogramTester to verify that the RRF logic works as intended.
Bug: 1421656
Change-Id: I1da14d8dc65e490aa546347e5db499a087a28430
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4579930
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreasson <henrika@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152152}
In this CL, we check if the continue_on url is same-origin with the config_url.
While it is not clear if this necessarily needs to be the case, it seems
like a safer privacy default that will cover the current known needs.
Bug: 1429083
Change-Id: I43887cc45895f985519ec93bec48cd1832e4aa78
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4581328
Commit-Queue: Sam Goto <goto@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152137}
The previous text selection menu logic for populating items was spread out, hard to understand, and heavily reliant on Android menu APIs. It was also used in two different places SelectionPopupControllerImpl & FloatingPastePopupMenu. Given that we are now planning to add a third menu type (see attached bug), it would be good to somehow centralize this logic while also making it generic enough for use with any menu rendering API. This means doing a few things.
1. Decoupling the menu item provision from the Android menu APIs.
2. Refactoring additional menu item providers (i.e. autofill) to be more generic and providing them to the SelectionPopupController.
3. Refactoring SelectionPopupControllerImpl && FloatingPastePopupMenu to use these new APIs.
All of this will need to be done while ensuring the current behavior does not change. This means when and in what order items show up should remain the same.
Follow up CLs starting at https://chromium-review.googlesource.com/c/chromium/src/+/4507323 will be used to implement a drop-down style menu that will leverage this refactor.
Bug: 1428022
Change-Id: Ic7ad00eb67275b9e4ecb8c8b1324bffb48e61b42
Low-Coverage-Reason: No logic changes in the classes mentioned, only a refactor. Also SelectionPopupControllerImpl has existing test coverage in SelectionPopupControllerTest (unit) & ContentTextSelectionTest (integration) which have been ran and pass locally.
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4547564
Reviewed-by: Peter Beverloo <peter@chromium.org>
Reviewed-by: Peter Conn <peconn@chromium.org>
Commit-Queue: Wayne Jackson Jr. <wbjacksonjr@chromium.org>
Reviewed-by: David Trainor <dtrainor@chromium.org>
Reviewed-by: Colin Blundell <blundell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152130}
