Implement <iframe allowpaymentrequest> in terms of feature policy |
||||||||
Issue description
The "allowpaymentrequest" iframe attribute should be implemented direcly in terms of Feature Policy, rather than the current implementation, which is an mahup of two different techniques: crawling the frame tree to the root, looking for either a chain of 'allowpaymentrequest' frames or an active policy.
If present on the iframe tag, allowpaymentrequest should translate into a declared policy
{ "paymentrequest": ["*"] }
for the purpose of calculating the inherited policy for the nested frame.
,
Jan 25 2017
On the spec side: * When a document is initialized (https://html.spec.whatwg.org/#creating-a-new-browsing-context and https://html.spec.whatwg.org/#initialise-the-document-object ), https://html.spec.whatwg.org/#set-the-allow*-flags is run, which can set "allowpaymentrequest flag" and "allowusemedia flag" on Document. * PaymentRequest constructor calls https://html.spec.whatwg.org/#allowed-to-use : https://github.com/w3c/browser-payment-api/pull/383 * getUserMedia also call allowed to use: https://github.com/w3c/mediacapture-main/pull/427 Relevant whatwg/html PRs: https://github.com/whatwg/html/pull/2195 https://github.com/whatwg/html/pull/2217 Relevant w3c/web-platform-tests PRs: https://github.com/w3c/web-platform-tests/pull/4369 https://github.com/w3c/web-platform-tests/pull/4615 I will write more tests for same origin-domain; see https://github.com/w3c/web-platform-tests/issues/4526
,
May 26 2017
We already did this right?
,
May 26 2017
Yes. Thanks for the triage! https://crrev.com/44b442a4f245e3fbfa17478bf0807cc139ab39ef implemented this.
,
Jul 18 2017
,
Oct 16 2017
Hi, I work on the Payment Request team. I'm trying to see if we can get this WPT test to pass (try in Dev or Canary): https://w3c-test.org/payment-request/allowpaymentrequest/setting-allowpaymentrequest-timing.https.sub.html IIUC, it tests that we do snapshotting correctly, and don't support if the "allowpaymentrequest" attribute is added after the iframe is attached. I don't know the state of feature policy (is it on?). Will it fix this test presumably? Our relevant code is here [1]. Thanks for any help. [1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/payments/PaymentRequest.cpp?rcl=9e2ec4dfde8f3c4c3075a1aac6f66455dfb9ef6d&l=809
,
Oct 16 2017
Yea I will take a look.
,
Oct 16 2017
Hi mathp@, could you please explain what is the test trying to do. I am not quite following the description / test. Thanks
,
Oct 16 2017
It's testing whether we will fail or succeed in the creation of the PaymentRequest object in an iframe. The test sets the "allowpaymentrequest" attribute on the iframe *after* it is attached to the DOM. IIUC, under the snapshotting concept, we should not honor the attribute if it's been added after the iframe was attached to the DOM.
,
Oct 17 2017
Indeed. Moreover, it is testing *when* the snapshot happens. If the snapshot happens when the response arrives, the test is intended to fail. From comment 2: > * When a document is initialized (https://html.spec.whatwg.org/#creating-a-new-browsing-context and https://html.spec.whatwg.org/#initialise-the-document-object ), https://html.spec.whatwg.org/#set-the-allow*-flags is run, which can set "allowpaymentrequest flag" and "allowusemedia flag" on Document.
,
Dec 5 2017
,
Dec 5 2017
Hi loonybear@, is there a particular change that fixed this issue? Thanks |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by rouslan@chromium.org
, Jan 18 2017