Bug 1517895 Comment 17 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

> a third scroll offset restoration path

Which are those three paths? One is `RestoreState()` in the scroll frame, the other `SessionStoreUtils.RestoreScrollPosition()`, and the third...?

I.e. did you also come across the `DocShell`'s [scroll position restoring](https://searchfox.org/mozilla-central/rev/00c0d068ece99717bea7475f7dc07e61f7f35984/docshell/base/nsDocShell.cpp#5628)? Unfortunately I don't know whether that bit is sufficiently covered by any tests, but basically that code path should be encountered in conjunction with anchor link or `pushState` navigation happening inside the same document. I.e. the scroll frame and its `PresState` can naturally only save one scroll position per document, but through anchor links or `pushState` URL-rewriting you can get multiple [Session History entries](https://searchfox.org/mozilla-central/rev/00c0d068ece99717bea7475f7dc07e61f7f35984/docshell/shistory/nsISHEntry.idl#229-234) for the same document. So those additional scroll positions are saved as part of the respective `SHEntry` and restored on navigation through the DocShell.
> a third scroll offset restoration path

Which are those three paths? One is `RestoreState()` in the scroll frame, the other `SessionStoreUtils.RestoreScrollPosition()`, and the third...?

I.e. did you also come across the `DocShell`'s [scroll position restoring](https://searchfox.org/mozilla-central/rev/00c0d068ece99717bea7475f7dc07e61f7f35984/docshell/base/nsDocShell.cpp#5628)? Unfortunately I don't know whether that bit is sufficiently covered by any tests (it certainly isn't in Android-specific tests), but basically that code path should be encountered in conjunction with anchor link or `pushState` navigation happening inside the same document. I.e. the scroll frame and its `PresState` can naturally only save one scroll position per document, but through anchor links or `pushState` URL-rewriting you can get multiple [Session History entries](https://searchfox.org/mozilla-central/rev/00c0d068ece99717bea7475f7dc07e61f7f35984/docshell/shistory/nsISHEntry.idl#229-234) for the same document. So those additional scroll positions are saved as part of the respective `SHEntry` and restored on navigation through the DocShell.
> a third scroll offset restoration path

Which are those three paths? One is `RestoreState()` in the scroll frame, the other `SessionStoreUtils.RestoreScrollPosition()`, and the third...?

I.e. did you also come across the `DocShell`'s [scroll position restoring](https://searchfox.org/mozilla-central/rev/00c0d068ece99717bea7475f7dc07e61f7f35984/docshell/base/nsDocShell.cpp#5628)? Unfortunately I don't know whether that bit is sufficiently covered by any tests (it certainly isn't in Android-specific tests, and any tests written with desktop in mind probably don't encounter the case where layout viewport != visual viewport), but basically that code path should be encountered in conjunction with anchor link or `pushState` navigation happening inside the same document. I.e. the scroll frame and its `PresState` can naturally only save one scroll position per document, but through anchor links or `pushState` URL-rewriting you can get multiple [Session History entries](https://searchfox.org/mozilla-central/rev/00c0d068ece99717bea7475f7dc07e61f7f35984/docshell/shistory/nsISHEntry.idl#229-234) for the same document. So those additional scroll positions are saved as part of the respective `SHEntry` and restored on navigation through the DocShell.
> a third scroll offset restoration path

Which are those three paths? One is `RestoreState()` in the scroll frame, the other `SessionStoreUtils.RestoreScrollPosition()`, and the third...?

I.e. did you also come across the `DocShell`'s [scroll position restoring](https://searchfox.org/mozilla-central/rev/00c0d068ece99717bea7475f7dc07e61f7f35984/docshell/base/nsDocShell.cpp#5628)? Unfortunately I don't know whether that bit is sufficiently covered by any tests [1], but basically that code path should be encountered in conjunction with anchor link or `pushState` navigation happening inside the same document. I.e. the scroll frame and its `PresState` can naturally only save one scroll position per document, but through anchor links or `pushState` URL-rewriting you can get multiple [Session History entries](https://searchfox.org/mozilla-central/rev/00c0d068ece99717bea7475f7dc07e61f7f35984/docshell/shistory/nsISHEntry.idl#229-234) for the same document. So those additional scroll positions are saved as part of the respective `SHEntry` and restored on navigation through the DocShell.

[1] It certainly isn't in Android-specific tests, and any tests written with desktop in mind probably don't encounter the case where layout viewport != visual viewport.

Back to Bug 1517895 Comment 17