[wp-trac] [WordPress Trac] #58978: Post embed iframe throws soft(?) DOMException for emoji-loader's references to sessionStorage

[WordPress Trac]

#58978: Post embed iframe throws soft(?) DOMException for emoji-loader's references
to sessionStorage
--------------------------+--------------------------
 Reporter:  westonruter   |       Owner:  westonruter
     Type:  defect (bug)  |      Status:  assigned
 Priority:  normal        |   Milestone:  6.3
Component:  Emoji         |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  javascript
--------------------------+--------------------------
Description changed by westonruter:

Old description:

> While working on #58931 I discovered that a post embed from a site
> running WordPress 6.3-RC3 was causing an error to appear in the console:
>
> {{{
> Uncaught (in promise) DOMException: Failed to read the 'sessionStorage'
> property from 'Window': The document is sandboxed and lacks the 'allow-
> same-origin' flag.
>     at getSessionSupportTests
> (http://localhost:8889/2023/06/07/emoji/embed/:83:3)
>     at http://localhost:8889/2023/06/07/emoji/embed/:354:22
>     at new Promise (<anonymous>)
>     at wpEmojiLoader
> (http://localhost:8889/2023/06/07/emoji/embed/:353:2)
>     at http://localhost:8889/2023/06/07/emoji/embed/:438:4
> }}}
>
> Then when I wrap `getSessionSupportTests` in a try/catch block, I see
> another error appear:
>
> {{{
> Uncaught DOMException: Failed to read the 'sessionStorage' property from
> 'Window': The document is sandboxed and lacks the 'allow-same-origin'
> flag.
>     at setSessionSupportTests
> (http://localhost:8889/2023/06/07/emoji/embed/:115:3)
>     at worker.onmessage
> (http://localhost:8889/2023/06/07/emoji/embed/:379:6)
> }}}
>
> Wrapping that instance with a try/catch block then causes the errors to
> be suppressed. The issue is that Post Embed iframes lack the `allow-same-
> origin` value for the `sandbox` attribute, and so `sessionStorage` is not
> available.
>
> What's surprising about this is even though an error appears in the
> console about an uncaught exception being thrown, I don't see the
> execution actually being interrupted anywhere. If I add code like this to
> `wp-embed`:
>
> {{{#!js
> console.log( 'sessionStorage', sessionStorage );
> console.log( 'sessionStorage.getItem("foo")',
> sessionStorage.getItem("foo") );
> console.log( 'Howdy!' );
> }}}
>
> Then sure enough my console reads:
>
> {{{
> typeof sessionStorage === object
> sessionStorage.getItem("foo") === null
> Howdy!
> Uncaught (in promise) DOMException: Failed to read the 'sessionStorage'
> property from 'Window': The document is sandboxed and lacks the 'allow-
> same-origin' flag.
> }}}
>
> And the callstack points to the exception being raised at `typeof
> sessionStorage === object`, even though the subsequent lines still
> execute.
>
> I introduced the use of `sessionStorage` in #58472. I had added try/catch
> blocks around the calls to `sessionStorage.getItem()` and
> `sessionStorage.setItem()` didn't thinking that code like this could
> possibly cause an error:
>
> {{{#!js
> if (
>         typeof sessionStorage !== 'undefined' &&
>         sessionStorageKey in sessionStorage
> ) {
> }}}
>
> But it does. It seems Chrome will at least emit a silent `DOMException`
> the first time that the `sessionStorage` object is touched. It doesn't
> seem to impact the execution, however.
>
> So fixing this will clear up errors from the console, but it doesn't seem
> it will have any other impact.

New description:

 While working on #58931 I discovered that a post embed from a site running
 WordPress 6.3-RC3 was causing an error to appear in the console:

 {{{
 Uncaught (in promise) DOMException: Failed to read the 'sessionStorage'
 property from 'Window': The document is sandboxed and lacks the 'allow-
 same-origin' flag.
     at getSessionSupportTests
 (http://localhost:8889/2023/06/07/emoji/embed/:83:3)
     at http://localhost:8889/2023/06/07/emoji/embed/:354:22
     at new Promise (<anonymous>)
     at wpEmojiLoader (http://localhost:8889/2023/06/07/emoji/embed/:353:2)
     at http://localhost:8889/2023/06/07/emoji/embed/:438:4
 }}}

 Then when I wrap `getSessionSupportTests` in a try/catch block, I see
 another error appear:

 {{{
 Uncaught DOMException: Failed to read the 'sessionStorage' property from
 'Window': The document is sandboxed and lacks the 'allow-same-origin'
 flag.
     at setSessionSupportTests
 (http://localhost:8889/2023/06/07/emoji/embed/:115:3)
     at worker.onmessage
 (http://localhost:8889/2023/06/07/emoji/embed/:379:6)
 }}}

 Wrapping that instance with a try/catch block then causes the errors to be
 suppressed. The issue is that Post Embed iframes lack the `allow-same-
 origin` value for the `sandbox` attribute, and so `sessionStorage` is not
 available.

 What's surprising about this is even though an error appears in the
 console about an uncaught exception being thrown, I don't see the
 execution actually being interrupted anywhere. If I add code like this to
 `wp-embed`:

 {{{#!js
 console.log( 'sessionStorage', sessionStorage );
 console.log( 'sessionStorage.getItem("foo")',
 sessionStorage.getItem("foo") );
 console.log( 'Howdy!' );
 }}}

 Then sure enough my console reads:

 {{{
 typeof sessionStorage === object
 sessionStorage.getItem("foo") === null
 Howdy!
 Uncaught (in promise) DOMException: Failed to read the 'sessionStorage'
 property from 'Window': The document is sandboxed and lacks the 'allow-
 same-origin' flag.
 }}}

 And the callstack points to the exception being raised at `typeof
 sessionStorage === object`, even though the subsequent lines still
 execute.

 I introduced the use of `sessionStorage` in #58472. I had added try/catch
 blocks around the calls to `sessionStorage.getItem()` and
 `sessionStorage.setItem()` didn't thinking that code like this could
 possibly cause an error:

 {{{#!js
 if (
         typeof sessionStorage !== 'undefined' &&
         sessionStorageKey in sessionStorage
 ) {
 }}}

 But it does. It seems Chrome will at least emit a silent `DOMException`
 the first time that the `sessionStorage` object is touched. It doesn't
 seem to impact the execution, however.

 So fixing this will clear up errors from the console, but it doesn't seem
 it will have any other impact.

 Note this issue can be reproduced with a post embed from the same site
 running on the wordpress-develop dev environment.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58978#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform