@wanderview hey Ben! Am I missing something here or is this still an issue? Seems like an important one for mobile especially PWAs, etc. https://bugzilla.mozilla.org/show_bug.cgi?id=251784#c10 …
-
-
Replying to @HenrikJoreteg
Sorry, this is outside the small area where I pretend I know something. Maybe
@bz_moz or smaug know the history here.2 replies 0 retweets 2 likes -
Replying to @wanderview @HenrikJoreteg
That page explicitly does document.body.scrollTop = 0, no? The question is whether it does it _before_ or _after_ browsers restore the scroll state. And browsers might differ on that.
2 replies 0 retweets 0 likes -
Hey Boris! I left this comment on the bug but that code only runs when the app causes the navigation, not when clicking "back". You can put a breakpoint there to verify. Sorry I should have done a better reduced test case.
2 replies 0 retweets 0 likes -
Replying to @HenrikJoreteg @wanderview
OK, so I dug more. This is not a normal navigation; it's a pushstate/popstate setup. We attempt to restore the scroll position right after firing the popstate event. The scroll gets clamped to content height, which at this point is 0....
1 reply 0 retweets 2 likes -
Note that per spec scroll restoration is supposed to happen immediately after firing popstate. See https://html.spec.whatwg.org/multipage/browsing-the-web.html#history-traversal … step 16
1 reply 0 retweets 1 like -
So, what should a single page app do in this scenario?
2 replies 0 retweets 0 likes -
Replying to @HenrikJoreteg @wanderview
The idea is that you generate your new content from the popstate event before returning from it. Apps that can't do that save/restore scroll position themselves, because the browser has no way to tell when you're done with that...
1 reply 0 retweets 0 likes -
If you already _are_ generating all the content before returning from the popstate handler, please let me know and I will look into why that ends up not working in Firefox.
1 reply 0 retweets 1 like -
I just walked through it with the debugger and yes, the new content is being generated before returning from that handler. (Breakpoint at 3551 in that example) The really odd thing is that when walking through it with the debugger it *does* restore scroll position (FF v58.0.2)
1 reply 0 retweets 0 likes
If I examine the DOM right after returning from the handler, all it has is: <div id="app"></div>, a script tag, and the <nav> bits. The rest of the content is generated later, asynchronously. A debugger breakpoint spins the event loop, letting the async bits complete...
-
-
Also, this is a terrible medium for this conversation; I can't even paste a small HTML snippet without hitting the char limit. ;) Anyway, I did find a bug in Firefox while looking into this: <https://bugzilla.mozilla.org/show_bug.cgi?id=1442958 …>. But fixing that is not enough to make your example work.
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.