forked from chromium/chromium
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[External intents] Use delegate's Context(Wrapper) rather than Activity
I will shortly be moving //chrome's implementation of warning the user on launching an intent incognito mode into ExternalNavigationHandler itself for reuse by WebLayer. However, there is a wrinkle that I need to solve in order to do so: in WebLayer, the string resources that are fetched from the Context in order to build the alert dialog are only available from the delegate impl's ContextWrapper that wraps the Activity, not from the Activity itself. This is because that ContextWrapper implements special logic to fetch the resources via the Context of the embedder. To solve this wrinkle and facilitate the upcoming componentization, this CL does the following: 1. Changes ExternalNavigationDelegate#getActivityContext() to ExternalNavigationDelegate#getContext(). 2. Changes the two ExternalNavigationHandler sites that interact with this method via ExternalNavigationHandler#getAvailableContext() to explicitly handle logic for the case where the delegate's Activity is available/not available explicitly. 3. Moves ExternalNavigationHandler#getAvailableContext() into //chrome's ExternalNavigationDelegateImpl, as it is now only used in //chrome. 4. Relaxes //chrome's ExternalNavigationDelegateImpl#startIncognitoIntentInternal() to check that its Context *wraps* an Activity rather than *is* an Activity in preparation for componentizing this method and invoking it via the WebLayer embedder, where the Context returned from ExternalNavigationDelegate#getContext() will indeed wrap rather than be an Activity. Note that the creation of an alert dialog does not require that the passed-in Context *be* an Activity. I investigated where the original check came from, and it was from a CL that was eliminating ExternalNavigationDelegateImpl.java caching an Activity field in an ivar as part of supporting tab reparenting (https://codereview.chromium.org/1636573004/). In that context, the check appears to be simply verifying whether the Tab is actually associated with an Activity or not. The current check preserves the conceptual verification. Bug: 1063399 Change-Id: I3de91f43e17d4691a8a67f81bb5091280ae1fc3b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2283604 Commit-Queue: Colin Blundell <blundell@chromium.org> Reviewed-by: Michael Thiessen <mthiesse@chromium.org> Cr-Commit-Position: refs/heads/master@{#787182}
- Loading branch information
1 parent
2429fa4
commit dc02d32
Showing
5 changed files
with
36 additions
and
33 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters