Closed Benjadahl closed 1 year ago
What do you think of returning the connect
from createPersistentPort
as an alias like forceReconnect
etc. and have content-script.ts
do the check and trigger the re-connect if necessary? Just thinking if we can keep the concerns isolated to where they truly belong
What do you think of returning the
connect
fromcreatePersistentPort
as an alias likeforceReconnect
etc. and havecontent-script.ts
do the check and trigger the re-connect if necessary? Just thinking if we can keep the concerns isolated to where they truly belong
That would definitely make sense. I can probably take a look at it later this week. :)
Turns out issue #42 was cause by the use of BF cahing in Safari: https://web.dev/bfcache/
BF caching takes the entire JS heap into a cache and reloads this instantly when using the back/forward buttons. The page state is restored from memory instead of being reloaded. This means that our connections would be disconnected when you navigate to a new page, and navigate back again. Example:
Thus the solution is to reconnect them, when the onpageshow event is called, if the persisted field is true.
@zikaari should this event be wrapped in a check for if window is defined in the context? I don't seem to be getting any runtime errors now, but maybe you know of any cases where it would be necessary?