-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix scrollpos after returning from download in iOS pwa mode #2782
Fix scrollpos after returning from download in iOS pwa mode #2782
Conversation
…s-restore compatible with bfcache
The reason Otherwise, you might see pictures that require a review when you navigate back or forward to Note that with my next commit, I will change the frontend routes to be prefixed with |
@lastzero then maybe a solution could be to only reset lastFilter when the routeName changes. Do you think that could work? |
Might work!? Current implementation was meant as a workaround until we find a better solution. You could force the router to always reload everything, but that's hurting performance. |
Will Test it later today, by first checking if the issues you mention happen for me when not resetting lastFilter at all, and then testing if these issues dissaperar when only resetting on routName-change. If that works for both cases (the issues you mentioned and the returning from fullscreen-Download) then we have a winner |
I think it is used to figure out if the cached results need to be replaced (otherwise they can just be displayed or an offset can be used to retrieve more results from the server). Unfortunately I have no idea how this would work in combination with Apple's caching. |
Make sure you also check the raw request data and not just what is displayed in the UI, as I recently added server-side logic to prevent content in review from being displayed by accident and tampering. This is part of our security enhancements for multi-user support. |
…t use the same components but with different settings
@lastzero your hint with why the lastFilter was reset was completely right, and it looks like my idea with the
I still need to check wether the raw-request data is fine, but i have a guess that they probably are. As for the cached-and-restored state of the website: If i understood it correctly, from the websites point of view, it is 100% as if the user had never left. The whole in-memory-state of the website gets cached and restored as if nothing happened at all. That is also why components don't rerender upon return |
Excellent work, as always! We should test it again, but it sounds plausible that it can work this way, since the configuration of the page component depends mainly on the route, e.g. which static search filters to use. Dynamic filters and other settings, on the other hand, should be restored as they were by the URL query parameters. There are two special cases to keep in mind:
Let me know when you want this to be merged! 👍 |
just tested these special cases, and it looks like they work just fine. But that makes sense! Thinking about it in a different way: if the route is unchanged, and the filter is unchanged, then the results should probably also not change!
Do you know of any cases where a new search needs to be triggered upon |
@lastzero From my point of view this can be merged, but maybe we should wait for feedback from @graciousgrey. She was the one who found the original bugs this fixes, and if i recall correctly, she wanted to test these changes anyway. |
Sorry for the conflicts! 🤣 |
Can't look at them right now. I'll quickly resolve the conflicts once I'm at my laptop |
Renamed the pages folder to page for consistency. |
strange that github showed conflicts there. i was able to merge cleanly, because git detected that the files were just renamed |
Thanks! I'll merge this now so we can test it on our demo and the temporary |
Just tested all cases again on different devices/browsers/pwa. Works perfect ❤️ |
As it turns out, iOS in PWA mode uses something called bfcache (backward-forward-cache) to cache the state of the whole webpage before navigating to the fullscreen-download-page, and restores the whole page from that cache after returning to the website.
The regular scrollpos-restore-mechanism found in
app.js
just doesn't support that bfcache-scenario. To fix this, i made the regular scrollpos-restore-mechanism compatible with bfcache scnearios bypageshow
andpagehide
eventsTo make it fully work i also skipped resetting
lastFilter
in the$route
-watcher of album-photos and search-view. That way the search-method detects that the filter is unchanged and skips the search, thus not resetting the scrollpos to0,0
. i'm not 100% sure why thelastFilter
was always being reset on every$route
change before and hope that that doesn't break anything.I expect the potential for new bugs caused by these fixes to otherweise be very small, because other than ios-pwa-fullscreen-downloads, there is barely any scenario where
pageshow
orpagehide
are triggered, especially withevent.persisted === true
.Acceptance Criteria: