Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Adapt to simplified flow of programmatically showing popups
Chromium change: https://source.chromium.org/chromium/chromium/src/+/072b6bf1b7db7f8b8cf2e2e3127a98a6b859d7bb commit 072b6bf1b7db7f8b8cf2e2e3127a98a6b859d7bb Author: Devlin Cronin <rdevlin.cronin@chromium.org> Date: Tue Feb 8 19:40:21 2022 +0000 [Extensions UI] Simplify the flow of programmatically showing popups Extensions can programmatically open their toolbar action popups. Before this CL, the flow for this was: API Call -> ExtensionsToolbarContainer::ShowToolbarActionPopupForAPICall() -> ExtensionActionViewController::ExecuteAction() (#1) -> ExtensionActionViewController::ExecuteAction() (#2) -> TriggerPopup() This has the following issues: - ExecuteAction() is also used for executing other types of behaviors (like triggering an event listener), not just for opening popups. - ExecuteAction() may grant the extension tab permissions if it was indicated that the call was through a user gesture Both of these aren't *technically* issues, since we theoretically validate that the extension will open a popup (and not fire a listener) and never trigger the call as a user gesture. But, it's a tenuous balance. Refactor this to introduce a public TriggerPopupForAPI() method on ExtensionActionViewController that ExtensionsToolbarContainer can call directly. This clears up the issues above by making the contract and expectations clear, and ensures that there's no way we'd ever grant tab permissions or fire an event for a programmatic API call. As a bonus, we simplify the interface by removing one of the ExecuteAction() overloads and the need to specify `by_user` in the call, instead just having ExecuteUserAction(). This will also make it easier to plumb through a callback for programmatic API calls when we need to wait for the popup to open. Bug: 1245093
- Loading branch information