Should we fire the launch event for in-scope navigations.
Closed this issue · 1 comments
For example:
A link to an in-scope document is clicked. This document is already open in another tab, so when the launch event is fired, the service worker focuses the tab that the document is already open in, as opposed to opening a new tab.
Issues:
This has a similar problem to the service worker fetch API: For all in scope navigation, we would have to communicate with the worker to determine what to do with the navigation, which, as we've found out, has a not insignificant performance overhead.
Proposed Position:
We only fire the launch event for out-of-scope navigations to in-scope urls. Apps can already control how they open links (e.g. by posting a message to their service worker), and this lets them control how they behave when linked to from an external site while not sacrificing performance for internal navigations.
Other Approaches:
Register launch events in documents (e.g. document.addEventListener('launch', ...)), avoiding the need to communicate with the service worker. This would require some method of inspecting and controlling SW clients from the document.
Accept the performance cost: For all in scope links, fire the launch event, consequences be damned. This would mean that all the advantages of the declarative routes proposal would be lost if a page also implemented a launch handler.
Some kind of declarative API (e.g. always restrict '/document/:id' links only having one page open but multiple '/documents' pages are fine). This could be worth more investigation, but part of the reason it seems to be a good idea for fetch handlers is because there is the option of writing code in a service worker, for more complicated cases. If we implement the proposed solution, it may be worth investigating this more if it seems to be causing significant performance problems down the line.
Wrong repository