Initial implementation of Web Payments feature #143
Conversation
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
mshin-wolvic
approved these changes
Dec 5, 2024
svillar
requested changes
Jan 13, 2025
| @@ -363,6 +363,10 @@ blink::mojom::PermissionStatus WolvicPermissionManager::GetPermissionStatus( | |||
| blink::PermissionType permission, | |||
| const GURL& requesting_origin, | |||
| const GURL& embedding_origin) { | |||
| if (permission == blink::PermissionType::PAYMENT_HANDLER) { | |||
| return blink::mojom::PermissionStatus::GRANTED; | |||
| } | |||
There was a problem hiding this comment.
Hmm I think we should still ask for this permission anyway
There was a problem hiding this comment.
We can, I guess, but bear in mind that Chrome Desktop doesn't do it.
There was a problem hiding this comment.
As a matter of fact, the Chromium code that handles the web payment method manifest downloading expect the permission to be GRANTED by default. I don't think we can ask the user about this.
This patch adds onCreateNewPaymentHandler method in WebContentsObserver to deliver the payment handler's WebContents to Wolvic side.
The PaymentUiService should not re-use the WindowAndroid instance from the original WebContents and, instead, must create a new one for the main activity. Additionally, this change also implements the close() method, so that we can properly destroy the newly created WebContent instance for the payment handler.
We need to detect when the user dismiss the Payment Handler UI so that we can close properly the ongoing Payment Request. For now observing the the destruction of the PaymentHandler's WebContent instance is the only way we have to detect this situation.
ns-mshin
approved these changes
Jan 20, 2025
mshin-wolvic
approved these changes
Jan 20, 2025
This new class can be used to create instance of Tabs that can handle PaymentHandler work-flow. The Client interface provides an API to control the window's life-cycle.
javifernandez
force-pushed
the
web-payments
branch
from
c2a4ce7 to
11df912
Compare
…Client interface Now that the WolvicPaymentUiService implements the PaymentRequestUI.Client interface we can use it to control the PaymentHandler window's life-cycle. In order to do this, we need to create the PaymentRequestUI instance in Chromium, and getting it in Wolvic from the WebContents received in the onCreateNewPaymentHandler. The current design didn't allow to call the WebContentImpl::getOrSetUSerData method, becuase it'd require the PaymentRequestUI to have a sinple consrtuctor with just one WebContents parameter. Additionally, this WebContents instance might be already initialized, which is not the case of our current design. So the solution to implement the PaymentRequestUI::getFromContents was to add a new public method in the WebContentsImpl class to directly set userData as an already created object.
mshin-wolvic
approved these changes
Jan 21, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR provides a very basic implementation of the Payment Request API and the minimum viable logic for the Payment Handlers.
In the latter case, it provides support just to launch a new tab that loads a service worker provided by the payment request.
A new modal window will be launched to load the service worker. This window is controlled by the WolvicPaymentUiService class, which will handle the service-worker result of the generate the payment request response.
A new ServiceTabLauncher class is implemented in Wolvic in order to launch this kind of modal dialogs.
Finally, this PR adds a new method in the WebContentsObserver to notify Wolvic when the new payment-handler WebContent instance is ready to be loaded in the modal window.