Google docs editor iframe

[joaosaro]

Hi!

I was reading the documentation related to third-party cookie deprecation, and if I understood, the only solution for Google Docs iframe is the published version. However, it's possible to embed the editor until the third-party cookie deprecation. CHIPS approach would need to be necessary on Google's side, so it isn't currently a solution.

After the phasing out, is there a way to embed Google Docs editor?

Thanks in advance

[lghall]

Hello! The Google Docs editor can already be embedded in browsers that don't support 3p cookies. Feel free to test it out in Firefox and Safari. The user will be shown a button to grant storage access to the iframe. The same solution is rolling out in Chrome ahead of 3p cookie deprecation.

[joaosaro]

Hi @lghall 👋

I was testing, and sometimes, it shows a UI requiring permission from the user, but it only shows up occasionally. It's something under development? Is there any documentation to check how to embed correctly? From what I read, we should embed the published version, but we want the editor.

Most of the time, I'm getting this UI from iframe:

I'm using #test-third-party-cookie-phaseout flag, and Third parties cookies option disallowed

P.S.: Initially, I thought Chrome would be the first browser to block third parties, but If I got it right, it means both Firefox/Safari are already blocked by default. Testing there shows this UI. I have seen it when trying with Chrome and the experiment flag, but it only shows once in many times.

[joaogue]

Hey @lghall!

Just to be sure, is this rollout for Chrome to be completed before the beginning of the 1% release of the 3p cookies? And if so is it possible to have an ETA?

[lghall]

Yes, the rollout for Chrome will be completed by the end of 2023.

[tadamcz]

Thank you so much @lghall for the helpful information!

I was worried this change would cripple my application (some reporting seemed to suggest embedding would be reduced to a read-only "Google Docs publishing URL", which I now understand will not be the case).

It's great that the Google Workspace team has already thought about this and implemented the necessary access requests (I believe using this API). I can confirm this works in Safari when a document is private.

---

There is one remaining issue: when a document is shared to "anyone with the link can view", the iframe does not understand it should request the permission, and just shows the document as a non-logged-in user. However, being logged in may be necessary if the user has edit access to the document. These screenshots from Safari should demonstrate what I mean.	Screenshots
Shared to anyone with the link ➡️ ❌ iframe incorrectly does not request access:
Not shared ➡️ ✅ iframe correctly requests access:

If I should open an issue about this somewhere else, let me know. Thanks!

[lghall]

Great point! I've added this issue to our internal tracking and I'll report back here if/when we're able to address it.

As an interim solution, you could ask users of your application to allowlist 3p cookies for the necessary pair in their browser if they encounter this particular issue.

[tadamcz]

Thanks!

I understand it's a slightly tricky one, as you may not wish to request the permission for all embedded documents that have "anyone with the link can view" as soon as they are loaded. However, some sort of long-term solution would be great, because the current behaviour is puzzling to users: if you click on the sign in button in the iframe, the browser redirects the entire page to the Google document (where the user is already signed in). So the permission request never appears.

I haven't thought about this very thoroughly, but one possible flow for documents with "anyone with the link can view" would be:

• when user clicks "sign in" within the iframe, request Storage Access permissions
  • if permission is refused, do the current behavior (redirect the entire page to the Google sign-in)
  • if permission is granted, check if the user is already signed in.
    • if yes, update the iframe contents as appropriate
    • otherwise, do the current behavior

[clementsimon]

Closing as there hasn't been any additional discussion on this thread in more than 6 weeks. Please re-open if there are any more questions or developments.

[lghall]

Hello! Circling back that we have now addressed the issue reported by tadamcz@ - If the user can View but not Edit the document without logging in, clicking "Sign in" will prompt for storage access and allow them to authenticate and edit the document if they have access. Thank you for the report!