? Intent to Bugfix: Do not clone sessionStorage when a window is created with noopener

[Eric Lawrence]

Chrome is currently failing a Web Platform test because a window created with rel=noopener (now the default for <a target="_blank">) clones the Session Storage of its opener, which it shouldn't since the spec changed 3 years ago.

https://crbug.com/771959 tracks the proposal to match the spec/Firefox and pass the WPT. 

The code change is simple, but there's clearly a potential compat implication. 

There do not appear to be many histograms for session storage access today (only for 3rd-party access and file:// access), but based on the ~15% of pageloads observed for the former, it does seem like DOM access is pretty common. However, that is an extreme upper-bound on the potential impact, since it counts all accesses, not just those of existing storage items in storage areas cloned illegally from an opener.

As discussed in the bug, it seems non-trivial to get more accurate metrics on impact. We could conceivably record on the SessionStorage object whether its contents were the result of a spec-violating Clone operation, and then log a histogram for the number of times such objects are accessed, but this would require significant new code and would still represent an over-estimate of the potential impact (since it would not track whether a given cloned storage item as accessed, or whether such access was meaningful to the behavior of the scenario).

Is this the sort of bugfix we could just run through the normal channels and watch for compat feedback? 

Or do we need to make a bigger telemetry investment before feeling confident in changing to match the spec?

thanks!

[Chris Harrelson]

Hi Eric,

Two questions:

- What is the expected failure mode for sites that don't expect the spec-compliant behavior?

- What does WebKit do?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e391c805-d40e-44d3-894c-94aed9cb745dn%40chromium.org.

[Eric Lawrence]

> What is the expected failure mode for sites that don't expect the spec-compliant behavior?

Such sites would find that any values that were set in sessionStorage in the first window would not be propagated to the second window. As to what would happen next, it's difficult to say: If the site or application required such values to function correctly, it would be broken. Whether a meaningful error message would show or not would be up to the site. 

Note that any such application would have started failing in Firefox over a year ago. Also note that sessionStorage is cloned, not shared,  so this was not a bidirectional communication mechanism between windows.

For a web developer to fix their site, it would have to explicitly add rel=opener to its links where sessionStorage cloning is required.

>- What does WebKit do?

Safari presently also has incorrect behavior; I filed https://bugs.webkit.org/show_bug.cgi?id=218804 against WebKit a week ago. A Radar link was generated by the WebKit Bug Importer, but thus far that is the extent of updates to the issue.

-Eric

[Chris Harrelson]

On Thu, Nov 19, 2020 at 8:19 AM 'Eric Lawrence' via blink-dev <blin...@chromium.org> wrote:

> What is the expected failure mode for sites that don't expect the spec-compliant behavior?

Such sites would find that any values that were set in sessionStorage in the first window would not be propagated to the second window.

With your bugfix, wouldn't the opposite happen, because the cloning will no longer happen?

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2fa6e4df-58d7-4137-9ec8-a00e5e75202an%40chromium.org.

[Eric Lawrence]

>>> What is the expected failure mode for sites that don't expect the spec-compliant behavior?

>> Such sites would find that any values that were set in sessionStorage in the first window would not be propagated to the second window.

> With your bugfix, wouldn't the opposite happen, because the cloning will no longer happen?

Perhaps we're saying the same thing.

Prior to my proposed change to match the spec:

   WindowA's sessionStorage contains {"someKey1": "someValue1","someKey2": "someValue2"} 
WindowA calls window.open("page2.html", "_blank", "noopener") to open a same-origin page in a new window.
   WindowB's sessionStorage  contains {"someKey1": "someValue1","someKey2": "someValue2"}

After my proposed change to match the spec:

   WindowA's sessionStorage contains  {"someKey1": "someValue1","someKey2": "someValue2"} 

WindowA calls window.open("page2.html", "_blank", "noopener") to open a same-origin page in a new window.  
   WindowB's sessionStorage contains {} 

After the change, if WindowB calls:

   let data = sessionStorage.getItem('someKey1');

then data is would be null. Prior to the change, it would have been "someValue1".

[Chris Harrelson]

Hi, the API owners met and are comfortable with you fixing the bug and trying to ship it. Please let us know if there are any issues. Thanks for asking! 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4b66c351-7e6b-463e-b24b-d26d6d7d3c09n%40chromium.org.