Closed Bug 1615078 Opened 5 years ago Closed 3 years ago

localStorage changes not picked up by new iframes until new write.

Categories

(Core :: Storage: localStorage & sessionStorage, defect, P3)

Product:
Core
Component:
Storage: localStorage & sessionStorage
Version:
68 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: franku, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.87 Safari/537.36

Steps to reproduce:

  • Own a static page at some URL.
  • Open page and set a localStorage key.
  • In an unrelated page (jsfiddle or otherwise), create an iframe to the above static page.
  • Inside the iframe, verify that the localStorage key is set from before.
  • Destroy the iframe in the auxiliary page.
  • From the static page, rewrite the same localStorage key to a different value .
  • In your auxiliary page, recreate an iframe at the static src again.

Actual results:

  • Observe that, within the iframe, the localStorage key is set to the value from the first write, not the second write.

Additionally, while the new iframe is up, you can re-write the key from the static page and see that the iframe begins picking up changes again.

Expected results:

I expected the iframe to have picked the second write and have an updated value.

Component: Untriaged → Storage: localStorage & sessionStorage
Product: Firefox → Core

Jan, can you please triage this?

Flags: needinfo?(jvarga)

Frank, can you reproduce the bug with a Nightly build ?

(ni for Comment#2)

Waiting for the reporter's feedback. Marking this P3 for now.

Flags: needinfo?(franku)
Priority: -- → P3
Flags: needinfo?(jvarga)

This was likely addressed by Local Storage Next Gen which was available on nightly at the time (hence comment 2's request to try on nightly) and is now available on release thanks to Bug 1599979. That said, note that if attempt to re-create this situation now, it is extremely likely that enhanced tracking protection will intervene, in which case the 4th bullet point from comment 0 will fail to see the value written from comment 2. This can be bypassed by disabling tracking protection for the the tab opened in the 3rd bullet point by clicking the shield on the left of the URL bar. Note that doing so will reload the tab and the iframe will need to be re-created.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(franku)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.