Safari ITP 2.0存储访问API-麻烦嵌套hasStorageAccess中的requestStorageAccess-非嵌套作品 [英] Safari ITP 2.0 Storage Access API - Trouble Nesting requestStorageAccess in hasStorageAccess - Non Nested Works

问题描述

我目前正在尝试实现调用存储访问API，但是在hasStorageAccess中嵌套对requestStorageAccess的调用时遇到了麻烦.

I'm currently trying to implement calling the storage access API, but am having trouble nesting the call to requestStorageAccess in hasStorageAccess.

这是代码的概述-这是相当标准的:

Here is an outline of the code - it's fairly standard:

  requestStorageAccessAndServe() {
    let thisObject = this;
    var promise = document.hasStorageAccess();
      promise.then(
        function (hasCookieAccess) {
          if (!hasCookieAccess) {
            document.requestStorageAccess().then(
                function successful() {
                  // reload iframe to run with cookie access
                  window.location.reload();
                },
                function fail() {
                  thisObject.serveContent();  // Code goes into here
                });
          } else {
            thisObject.serveContent();
          }
        },
        function (reason) {
          thisObject.serveContent();
        }
      );

  }

当单击按钮触发此方法时，我总是会陷入该失败"功能，而没有出现要求存储访问权限的提示.

When clicking on the button to trigger this method, I always fall into that "fail" function, with no prompt appearing to request storage access.

令人惊讶的是，这个非嵌套的代码可以完美地工作:

Surprisingly, this non-nested code works perfectly:

  requestStorageAccessAndServe() {
    let thisObject = this;
    let hasCookieAccess = !!document.cookie;
    if (!hasCookieAccess) {
      document.requestStorageAccess().then(
          function successful() {
            window.location.reload();
          },
          function fail() {
            thisObject.serveContent();
      });

    } else {
      thisObject.serveContent();
    }
  }

此代码有效-它在第一个请求上重新加载iframe，然后在另一个请求上重新加载数据后再提供数据，但是通过执行!! document.cookie来检查cookie访问是非常棘手的(如果其中没有cookie数据该怎么办?首先)，而我更想了解这里出了什么问题.有人知道吗?

This code works - it reloads the iframe on the first request and then serves the data after another request on reload, but checking for cookie access by doing !!document.cookie is extremely hacky (what if there is no cookie data in the first place), and I'm more trying to understand what is going wrong here. Does anyone have any idea?

对于一个可能的解决方案，有什么办法可以强制解决document.hasStorageAccess()，所以我不需要嵌套它?

For a possible solution, is there any way I can force resolve document.hasStorageAccess() so I don't need to nest it?

强迫诺言解决也无济于事.参见代码示例:

Forcing the promise to resolve did not help either. See code example:

  async requestStorageAccessAndServe() {
    let thisObject = this;
    let hasCookieAccess = await document.hasStorageAccess();
    if (!hasCookieAccess) {
      document.requestStorageAccess().then(
          function successful() {
            window.location.reload();
          },
          function fail() {
            thisObject.serveContent();
      });

    } else {
      thisObject.serveContent();
    }
  }

仍然进入失败"功能...

Still goes into that "fail" function...

推荐答案

此处的问题是requestStorageAccess()需要调用用户意图.通过将其嵌套在hasStorageAccess()承诺中，可以掩盖用户意图(单击)，并且Safari会自动拒绝该请求.

The problem here is that requestStorageAccess() requires user intent to be called. By nesting it in the hasStorageAccess() promise, that user intent (click) is obscured, and Safari rejects the request automatically.

为解决此问题，我在iframe加载时解析了hasStorageAccess(因为它不需要用户意图)，将此结果存储在一个类变量中，然后如果解析为false，则在单击时检查requestStorageAccess.

To counteract this, I resolve hasStorageAccess on iframe load (since it does not require user intent), store this result in a class variable, and then if it resolved to false, I check requestStorageAccess on click.

这篇关于Safari ITP 2.0存储访问API-麻烦嵌套hasStorageAccess中的requestStorageAccess-非嵌套作品的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！