웹 푸시 알림을 누르면 상세 페이지로: navigate와 클릭 이벤트 선택법
알림을 누르면 대화방은 열리는데, 클릭 이벤트에 넣어 둔 읽음 처리는 실행되지 않는다. navigate로 목적지를 지정하면 기존 클릭 코드는 어떻게 될까?

- 알림의 navigate 옵션에 URL을 넣으면 지원 브라우저가 클릭 후 목적지로 이동한다.
- 이 경로에서는 notificationclick 이벤트가 발생하지 않아 기존 핸들러의 추가 작업도 실행되지 않는다.
- 미지원 브라우저와 사용자 정의 클릭 동작에는 서비스 워커의 이벤트 처리 경로를 유지한다.
페이지 이동만 필요하면 알림을 만들 때 URL을 지정한다
메시지 알림을 누르면 해당 대화로, 배송 알림을 누르면 주문 상세로 보내고 싶다면 showNotification()의 navigate 옵션을 사용할 수 있다. Firefox 158은 10월 13일부터 이 옵션을 지원한다. 지원 환경에서는 목적지를 여는 클릭 리스너를 따로 작성할 필요가 없다.
MDN의 navigate 설명에 따르면 옵션에 전달한 URL은 알림 객체에서 해석된 절대 URL로 읽을 수 있다. 예컨대 서비스 워커에서 알림을 만들 때 navigate: "/messages/42"를 지정하면 사이트의 해당 메시지 페이지가 이동 대상이 된다.
이 설정은 이미 허용된 알림의 클릭 목적지를 정한다. 알림 권한이나 푸시 구독을 대신하지 않는다. 사용자가 버튼을 누르는 등의 동작에 맞춰 권한을 요청하고, 모바일까지 지원한다면 서비스 워커의 showNotification()을 사용하는 기본 조건은 그대로다.
navigate를 넣으면 기존 클릭 코드가 실행되지 않는다
단순 이동 코드를 줄일 수 있는 이유는 브라우저가 클릭 처리를 직접 맡기 때문이다. Notifications 표준의 활성화 절차는 이동 URL이 있으면 페이지 이동을 처리한 뒤 반환하도록 정한다. 그 뒤의 notificationclick 이벤트 발생 단계로 진행하지 않는다.
따라서 기존 핸들러에서 클릭 기록을 보내거나 읽음 처리를 수행했다면, 같은 알림에 navigate를 추가한 뒤에도 그 코드가 실행될 것으로 기대해서는 안 된다. 이동과 추가 작업을 모두 직접 처리해야 한다면 해당 알림에는 navigate를 넣지 않고 이벤트 경로를 유지한다.
열리는 창의 형태도 구분해야 한다. 표준은 기존 창을 이동시킬지 새 창을 만들지를 브라우저 구현에 맡긴다. URL을 지정하는 것만으로 항상 같은 탭이나 설치된 PWA 창을 재사용한다고 보장되지는 않는다.
지원 여부를 나누되 두 경로에 같은 목적지를 전달한다
2026년 10월 26일 확인한 MDN 호환성 데이터는 Firefox의 지원 버전을 158로 기록하지만 Chrome은 미지원으로 표시한다. 브라우저 이름만 보고 공통 코드를 바꾸기보다 속성 지원을 확인해 분기하는 편이 낫다.
다음은 메시지 42번으로 이동하는 서비스 워커 예다. 알림 권한과 푸시 구독이 준비된 상태에서 사용하며, 지원 환경은 navigate, 그 밖의 환경은 data.url을 읽는 클릭 핸들러를 사용한다. 예시의 제목과 URL은 서비스에 맞게 바꾼다.
self.addEventListener("push", (event) => {
const url = new URL("/messages/42", self.location.origin).href;
const options = { body: "A new message is ready", data: { url } };
if (typeof Notification !== "undefined" &&
"navigate" in Notification.prototype) {
options.navigate = url;
}
event.waitUntil(
self.registration.showNotification("New message", options)
);
});
self.addEventListener("notificationclick", (event) => {
event.notification.close();
const url = event.notification.data?.url;
if (url) event.waitUntil(self.clients.openWindow(url));
}); data.url 자체에는 이동 기능이 없다. 위 예제의 핸들러가 그 값을 읽어 openWindow()에 전달한다. 서비스 워커의 notificationclick은 일반 페이지의 onclick과 다른 위치에서 처리한다.
클릭 후 작업이나 기존 창 선택이 필요하면 이벤트 방식이 맞다
선택 기준은 이동 전후에 애플리케이션이 직접 해야 할 일이 있는지다. 아래 표는 알림 본문을 클릭하는 동작을 기준으로 한다.
| 필요한 동작 | 선택 |
|---|---|
| 지정한 상세 페이지로 이동한다 | 지원 환경에서 navigate를 사용한다. |
| 기존 클릭 핸들러에서 읽음 처리·기록 전송을 한다 | navigate를 넣지 않고 notificationclick을 유지한다. |
| 열린 창 중 특정 창을 찾아 포커스를 준다 | 핸들러에서 clients.matchAll과 focus 등을 사용한다. |
openWindow()는 서비스 워커에서 URL을 여는 메서드다. Firefox에서는 알림 클릭에 따른 호출일 때 팝업을 열 수 있다. 비동기 클릭 처리는 event.waitUntil()에 연결하는 공식 예제의 구조를 유지한다.
마지막으로 알림이 아예 뜨지 않는 문제와 클릭 후 이동 문제는 따로 확인해야 한다. 알림 API의 권한·HTTPS 조건을 충족해 표시가 되는지 확인한 뒤, 목적지 URL과 클릭 처리 경로를 점검하면 된다. 단순 이동에 navigate를 쓰고, 직접 처리할 일이 남은 알림은 이벤트 방식으로 유지하는 것이 전환의 기준이다.