fix: avoid using the problematic beforeunload event #344
Conversation
|
Huh – from the document, it seems like Seems like it might be more robust to listen for |
|
It looks like that, but my assumption (given the description for transition I don't think using the I agree though, the visibility is probably a better way to do it, given the description of the hidden state:
My only hesitation with that is that I think in the hidden state JS still runs, so in theory the user might be running code that scrolls the page (even though the user can't see it), and expecting If you're happy with that compromise I'll change to to use the pagevisibility events. |
|
My guess would be that using the |
|
Ah, shoot, forgot I had to reply to this. Hmm, the other thing I'm concerned about is the Perhaps the easy answer is to just listen to |
0a7f8b6 to
eb48f80
Compare
|
Yeah, I think you're right. I've changed it to use page-lifecycle to detect the transitions instead of manually listening to the events. This is what is recommended in that documentation, and it means we don't have to worry about browser differences (e.g. the |
| @@ -6,6 +6,7 @@ import scrollLeft from 'dom-helpers/query/scrollLeft'; | |||
| import scrollTop from 'dom-helpers/query/scrollTop'; | |||
| import requestAnimationFrame from 'dom-helpers/util/requestAnimationFrame'; | |||
| import invariant from 'invariant'; | |||
| import PageLifecycle from 'page-lifecycle/dist/lifecycle.es5'; | |||
There was a problem hiding this comment.
|
I'm a bit stumped on the test failures - I can't seem to increase the timeout. don't think the error has anything to do with the changes. |
There was a problem hiding this comment.
hmm, the regular dependabot CI is passing, though. i'm not sure what it could be other than some oddness with the polyfill?
do things fail if we just remove the beforeunload handler, i.e. were things depending on bad side effects of having installed that handler?
| } | ||
| this._hasSetScrollRestoration = true; | ||
| }; | ||
|
|
||
| _restoreScrollRestoration = () => { | ||
| /* istanbul ignore if: not supported by any browsers on Travis */ | ||
| if (this._oldScrollRestoration) { |
There was a problem hiding this comment.
so just bail if this._hasSetScrollRestoration is false?
There was a problem hiding this comment.
Ive replaced this with just _oldScrollRestoration as you suggested - does that look good?
fd0a32a to
9dc79fd
Compare
|
Tests were failing to to various things - should be fixed now :) |
|
really sorry for the delay here; it should not have taken me so long |
|
published as v0.10.0 |
Use of the
beforeunloadevent is problematic because when it is used, browsers generally avoid using the back/forward cache or freezing the page, because the (historically assumed) semantics of thebeforeunloadevent are incompatible with a page unloading and then loading again. Theunloadevent also has this problem, and is not triggered reliably on mobile browsers.So currently, any site that uses
scroll-behaviorand instantiates it at least once cannot be cached in a browsers back/forward cache, and cannot be frozen to save memory.See https://developers.google.com/web/updates/2018/07/page-lifecycle-api for details
The
pagehideandpageshowevents don't suffer from this problem and are well supported. To use them we must account for the possibility that an unloaded page might be loaded again (e.g. if it was frozen, or put in a browsers back/forward cache).