llm-wiki/raw/official-docs/mdn-broadcastchannel-storage-event.md

title, source_type, url, archive_url, related_branches, related_projects, tags, created

title	source_type	url	archive_url	related_branches	related_projects	tags	created
MDN — BroadcastChannel / Window storage event	official-doc	https://developer.mozilla.org/en-US/docs/Web/API/BroadcastChannel		feature-frontend-cache-tier-cross-tab-invalidation-contract	ca-skeleton-frontend	frontend cross-tab broadcastchannel web-storage browser	2026-07-28

MDN — BroadcastChannel / Window storage event

Layer: raw/ — 외부 자료의 원문 발췌·출처 기록.

활용 branch (필수, 최소 1개+)

Branch	이 자료가 정당화하는 결정
[[raw/branch-notes/feature-frontend-cache-tier-cross-tab-invalidation-contract]]	발신 컨텍스트 자기 수신 불가 처리(D4), 대체 경로를 두지 않는다는 결정(D5 — #C4 의 지원 범위와 #C10 의 sessionStorage 미도달), 메시지 봉투의 직렬화 제약(D2)

출처

• 원본 URL: https://developer.mozilla.org/en-US/docs/Web/API/BroadcastChannel
• 보조 URL: https://developer.mozilla.org/en-US/docs/Web/API/BroadcastChannel/postMessage , https://developer.mozilla.org/en-US/docs/Web/API/Window/storage_event
• 아카이브 URL:
• 저자 / 조직: MDN Web Docs (Mozilla)
• 발행일: (문서 지속 갱신)
• 마지막 확인일: 2026-07-28

왜 저장했는지

FE-D028 이 "BroadcastChannel 우선 + storage event fallback" 을 정했는데, 그 두 transport 의 실제 전달 범위를 확인하지 않은 채 adapter 를 설계하면 두 가지를 놓친다. (a) 두 transport 모두 발신자에게는 이벤트가 가지 않는다 — 로컬 무효화를 채널 왕복에 의존하면 발신 탭만 stale 로 남는다. (b) storage event 는 sessionStorage 에서도 발생하지만 그 경우 다른 탭에는 도달하지 않는다 — fallback backend 를 명시하지 않으면 조용히 동작하지 않는 fallback 이 된다. 추가로 BroadcastChannel 의 Baseline 상태가 fallback 유지 근거를 좌우한다.

핵심 인용

[§BroadcastChannel] "The BroadcastChannel interface represents a named channel that any browsing context of a given origin can subscribe to."

[§BroadcastChannel] "It allows communication between different documents (in different windows, tabs, frames or iframes) of the same origin."

[§BroadcastChannel] "Messages are broadcasted via a message event fired at all BroadcastChannel objects listening to the channel, except the object that sent the message."

[§BroadcastChannel — Note] "This feature is available in Web Workers."

[§BroadcastChannel — Baseline] "Baseline Widely available — This feature is well established and works across many devices and browser versions. It's been available across browsers since March 2022."

[§BroadcastChannel.close] "Closes the channel object, indicating it won't get any new messages, and allowing it to be, eventually, garbage collected."

[§BroadcastChannel.postMessage — Parameters] "The data is serialized using the structured clone algorithm."

[§BroadcastChannel.postMessage — Exceptions] "DataCloneError DOMException — Thrown if any part of the input data is not serializable."

[§BroadcastChannel.postMessage — Exceptions] "InvalidStateError DOMException — Thrown if the BroadcastChannel has already been closed."

[§Window: storage event] "The storage event of the Window interface fires when another document that shares the same storage area (either localStorage or sessionStorage) as the current window updates that storage area. The event is not fired on the window that made the change."

[§Window: storage event] "For localStorage, the event is fired in all other browsing contexts that are in the same origin as the initiating document. This includes other tabs with the same origin."

[§Window: storage event] "For sessionStorage, the event is fired in all other browsing contexts that are in the same origin and the same top-level browsing context as the initiating document. This only includes embedded iframes, if any, in the same tab, and not other tabs."

[§Window: storage event — Event properties] "The key attribute is null when the change is caused by the storage clear() method."

추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
C1	BroadcastChannel 은 같은 origin 의 서로 다른 문서(창·탭·frame·iframe) 사이 통신 수단이다	[§BroadcastChannel] "communication between different documents (in different windows, tabs, frames or iframes) of the same origin"	official-reference	같은 origin 의 browsing context	cross-origin 또는 다른 프로필/브라우저 간 전달
C2	메시지는 채널을 듣는 모든 BroadcastChannel 객체에 전달되되 보낸 객체만 제외된다	[§BroadcastChannel] "fired at all BroadcastChannel objects listening to the channel, except the object that sent the message"	official-reference	모든 수신 객체	발신 문서 전체가 제외된다는 뜻은 아님 — 제외 단위는 객체이므로 같은 문서의 다른 채널 객체는 수신한다
C3	BroadcastChannel 은 Web Worker 에서도 사용할 수 있다	[§Note] "This feature is available in Web Workers."	official-reference	worker 컨텍스트	service worker 에서의 생명주기 보장
C4	BroadcastChannel 은 Baseline Widely available 이며 2022년 3월부터 브라우저 전반에서 제공된다	[§Baseline] "It's been available across browsers since March 2022."	official-reference	Baseline 기준 브라우저 집합	이 프로젝트의 대상 브라우저 매트릭스가 그 집합 안이라는 뜻은 아님(FE-Q-007 미확정). private 모드·파티션 환경의 동작도 증명하지 않음
C5	postMessage 는 structured clone 으로 직렬화하며 직렬화 불가 데이터는 DataCloneError 를 던진다	[§postMessage] "serialized using the structured clone algorithm" / "Thrown if any part of the input data is not serializable"	official-reference	모든 BroadcastChannel 메시지	직렬화 가능하면 크기 제한이 없다는 뜻은 아님
C6	닫힌 채널에 postMessage 하면 InvalidStateError 가 발생한다	[§postMessage — Exceptions] "Thrown if the BroadcastChannel has already been closed."	official-reference	close() 이후의 발행	unmount 시 close 를 강제해야 한다는 정책까지 증명하지는 않음
C7	close() 는 더 이상 메시지를 받지 않음을 표시하고 GC 를 허용한다	[§close] "indicating it won't get any new messages, and allowing it to be, eventually, garbage collected"	official-reference	채널 객체 수명	close 를 빠뜨렸을 때의 누수 규모
C8	storage event 는 변경을 만든 window 에서는 발생하지 않는다	[§storage event] "The event is not fired on the window that made the change."	official-reference	localStorage·sessionStorage 양쪽	다른 문서에서는 반드시 발생한다는 타이밍 보장
C9	localStorage 변경의 storage event 는 같은 origin 의 다른 모든 탭에 도달한다	[§storage event] "For localStorage, the event is fired in all other browsing contexts that are in the same origin as the initiating document. This includes other tabs with the same origin."	official-reference	localStorage	값이 동일할 때도 발생하는지
C10	sessionStorage 변경의 storage event 는 같은 탭 안(same top-level browsing context)에만 도달하고 다른 탭에는 도달하지 않는다	[§storage event] "This only includes embedded iframes, if any, in the same tab, and not other tabs."	official-reference	sessionStorage	sessionStorage 를 캐시 tier 로 쓰는 것 자체가 잘못이라는 뜻은 아님 — 잘못은 이를 탭 간 신호로 쓰는 것
C11	clear() 로 인한 변경이면 StorageEvent.key 는 null 이다	[§Event properties] "The key attribute is null when the change is caused by the storage clear() method."	official-reference	storage event 수신부	null key 를 어떻게 처리해야 하는지의 정책

적용 경계

• 이 자료가 직접 증명하는 것:
  • C1~C7: BroadcastChannel 의 전달 범위·자기 제외·직렬화·수명
  • C8~C11: storage event 의 발신자 제외, backend 별 도달 범위, clear() 시 key 형태
• 이 자료가 증명하지 않는 것:
  • storage event 가 같은 값으로 덮어썼을 때도 발생하는지 — MDN 이 이 페이지에서 말하지 않는다. 신호 key 를 매번 다른 값으로 써야 하는지는 실측 필요
  • 두 transport 의 전달 지연이나 순서 보장 — 어느 쪽도 명시하지 않는다
  • BroadcastChannel 이 사용 불가한 실제 환경의 목록 — C4 의 Baseline 은 그 반대 방향의 증거다
• 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  • 대상 브라우저 매트릭스(FE-Q-007)에 BroadcastChannel 미지원 행이 실제로 있는지 — 없다면 FE-D028 의 storage event fallback 은 근거 없는 복잡도다

메모

• 인용 1 해석 후보 (미검증): C2 의 제외 단위가 객체라는 점 때문에, adapter 가 컨텍스트당 채널 객체를 1개만 유지하면 "발신 탭은 수신하지 않는다" 가 성립한다. 반대로 무심코 객체를 2개 만들면 자기 메시지를 자기가 받는 경로가 생긴다.
• 인용 2 해석 후보 (미검증): C8+C2 를 합치면 두 transport 모두 발신자에게 echo 하지 않는다. 따라서 로컬 무효화는 채널을 거치지 않고 직접 수행해야 한다는 설계 제약이 된다.
• 추가로 봐야 할 동일 출처 페이지: Window.localStorage 의 저장 한도, StorageEvent 인터페이스 자체

관련

• 같은 주제 다른 official-doc: [[raw/official-docs/mdn-storage-quotas-eviction-persistence]], [[raw/official-docs/tanstack-query-persistence-hydration-official]]
• 이 자료를 인용한 wiki 요약: 생성 전