[FOLLOWUP] CachedStorageArea c'tor signature changed.

Chromium change:

https://source.chromium.org/chromium/chromium/src/+/f33e440034f2ff39062fd6e834acf2babc6871a5

commit f33e440034f2ff39062fd6e834acf2babc6871a5
Author: Tsuyoshi Horo <horo@chromium.org>
Date:   Wed May 19 05:29:49 2021 +0000

    Reland "Reland "Use the same SessionStorageNamespace for prerendering""

    This reverts commit a0159268472a7ae35a8573518aacad4e4f758b12.

    Reason for revert: Fixed test failure by checking RenderProcessHost::run_renderer_in_process()

    Original change's description:
    > Revert "Reland "Use the same SessionStorageNamespace for prerendering""
    >
    > This reverts commit c226ef4e5aaa66edbf29db3239e91bd49bcac2d2.
    >
    > Reason for revert: PrerenderSingleProcessBrowserTest.SessionStorageAfterBackNavigation reliably failing
n linux-chromeos-chrome since first run with this
    > CL: https://ci.chromium.org/p/chrome/builders/ci/linux-chromeos-chrome/14428
    >
    > Original change's description:
    > > Reland "Use the same SessionStorageNamespace for prerendering"
    > >
    > > This is a reland of eefb8c561ab863863b0541125df363fef040eabb
    > >
    > > The original CL was reverted because the
    > > PrerenderBackForwardCacheBrowserTest was flaky. The test didn’t check
    > > the behavior of BackForwardCache. It was just running the same tests of
    > > PrerenderBrowserTest.SessionStorageAfterBackNavigation_NoProcessReuse or
    > > SessionStorageAfterBackNavigation_KeepInitialProcess. If the initial
    > > process have been killed before the back navigation, the test failed.
    > >
    > > To make the BackForwardCache logic work this CL changed the browser test
    > > as followings:
    > >   - Added enable_same_site flag.
    > >   - Stopped using BroadcastChannel which prevent BFCache.
    > >
    > > PS1 is the same as the original CL.
    > >
    > >
    > > Original change's description:
    > > > Use the same SessionStorageNamespace for prerendering
    > > >
    > > > Currently there is an issue that the Session Storage is not carried over
    > > > to the prerendering page. This is because a new Session Storage
    > > > Namespace is used for the prerendering page.
    > > >
    > > > To fix this issue, this CL changes PrerenderHost::PageHolder to copy the
    > > > Session Storage Namespace from the initiator page to the prerendering
    > > > page.
    > > >
    > > > We don’t want the Session Storage state in the storage service be
    > > > updated by the prerendering page. And we want to synchronize the Session
    > > > Storage state of the prerendering page with the initiator page when the
    > > > prerendering page is activated. So this CL introduces a flag
    > > > |is_session_storage_for_prerendering_| in CachedStorageArea, and make
    > > > CachedStorageArea not to send the changes of the Session Storage state
    > > > to the storage service, and make StorageArea recreate |cached_area_|
    > > > when the prerendering page is activated.
    > > >
    > > > This is the "clone & swap" mechanism for session storage in prerendering
    > > > described in whatwg/storage#119.
    > > >
    > > > This CL still has an issue that when the initial renderer process is
    > > > reused after the back navigation from a prerendered page, the Session
    > > > Storage state is not correctly propagated to the initial renderer
    > > > process. This issue will be fixed in the next CL.
    > > > https://crrev.com/c/2849654
    > > >
    > > > Bug: 1197383

chromium_src/third_party/blink/renderer/modules/storage/dom_window_storage.cc

@@ -227,7 +227,8 @@ StorageArea* BraveDOMWindowStorage::ephemeralLocalStorage() {
   controller->ClearAreasIfNeeded();
   auto storage_area = base::MakeRefCounted<CachedStorageArea>(
       CachedStorageArea::AreaType::kSessionStorage, window->GetSecurityOrigin(),
-      controller->TaskRunner(), namespaces->local_storage());
+      controller->TaskRunner(), namespaces->local_storage(),
+      window->GetFrame()->GetDocument()->IsPrerendering());
 
   // Ephemeral localStorage never persists stored data, which is also how
   // sessionStorage works. Due to this, when opening up a new ephemeral