commit | d86b902de8361f666fa88a338d24227c0851432c | [log] [tgz] |
---|---|---|
author | dmangal <dmangal@microsoft.com> | Thu Dec 05 06:49:20 2024 |
committer | Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> | Thu Dec 05 06:49:20 2024 |
tree | 16b5aa066c9b48965e0df4214ee51572bca9ac77 | |
parent | ff8e0ca4b99dabee7b01a11e578ffb1488b0717c [diff] |
[views-ax] Refactor tooltip text to be cached in HoldingSpaceItemChipView and PrivacyIndicatorsTrayItemView View specific changes: 1) HoldingSpaceItemChipView: The tooltip text is determined by the primary and secondary labels’ text, as well as their tooltip text itself. Therefore, we have added callbacks to handle all relevant cases. 2) PrivacyIndicatorsTrayItemView: The tooltip text depends on several factors, such as the `IsCameraUsed` or `IsMicrophoneUsed` functions of the controller. However, after each update, the `UpdateVisibility` function of PrivacyIndicatorsTrayItemView is called, covering all scenarios where the tooltip text might change. Thus, incorporating `UpdateVisibility` in our migration addressed all relevant cases. From previous CL description and tracking bug info: The tooltip text is used for accessible descriptions of Views. As a result, this is needed for the ViewsAX project, this is because this project involves caching accessible properties of Views rather than computing them "on the fly", and currently the tooltip text is not cached across all Views. Some Views do cache it locally (in those classes) but others just compute it on the fly. Due to the large number of Views and files involved, my aim is to complete this refactor iteratively across multiple CLs. In order for this to be possible, and to keep the View builder and the compiler happy, the refactor will be split into two separate parts, the implementation and the cleanup. For the implementation, we will have to use "clever" naming so that CLs can be largely independent and we keep compatibility with the View builder. As such, for now we will have `SetCachedTooltipText(string)` and `GetCachedTooltipText()` as the main entryways to get/set this new cached member (`cahed_tooltip_text_`) on View. The goal will be to eventually rename these to `SetTooltipText(string)`, `GetCachedTooltipText()`, and `tooltip_text_`, or something similar. However, for now, because some Views have their own version of `SetTooltipText(string)`, `GetTooltipText()` and the existing `GetTooltipText(point)`, we will use the `Cached` part in the naming to keep these separate. During the refactor, we will make these latter ones simply "point" towards the new ones that affect the new cached tooltip text on View. After all the instances of `GetTooltipText(point)` are refactored in this manner, I will go back and perform cleanup where it makes sense. Among possible action items for the clean up will be: * Rename to just `SetTooltipText(string)`, `GetTooltipText()` and `tooltip_text_`. * Remove `GetTooltipText(point)` * Remove or rename local instances of `GetTooltipText()` i.e. `Label::GetTooltipText()` etc and if possible use only the new one on View. This CL is part of the ViewsAX project: https://docs.google.com/document/d/1Ku7HOyDsiZem1yaV6ccZ-tz3lO2XR2NEcm8HjR6d-VY/edit#heading=h.ke1u3utej413 Bug: 325137417, 378724151 Change-Id: I8dca15892f58a4b115caa6286f556f3f966006d5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6051358 Commit-Queue: Divyansh Mangal <dmangal@microsoft.com> Reviewed-by: Xiyuan Xia <xiyuan@chromium.org> Reviewed-by: Elly FJ <ellyjones@chromium.org> Reviewed-by: Javier Contreras <javiercon@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1392092}
Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web.
The project's web site is https://www.chromium.org.
To check out the source code locally, don't use git clone
! Instead, follow the instructions on how to get the code.
Documentation in the source is rooted in docs/README.md.
Learn how to Get Around the Chromium Source Code Directory Structure.
For historical reasons, there are some small top level directories. Now the guidance is that new top level directories are for product (e.g. Chrome, Android WebView, Ash). Even if these products have multiple executables, the code should be in subdirectories of the product.
If you found a bug, please file it at https://crbug.com/new.