From 017a842ec6c63e6ed4f26f77da41270688eab33e Mon Sep 17 00:00:00 2001 From: Majid Valipour Date: Tue, 15 Dec 2015 17:47:51 -0500 Subject: [PATCH] Clarify manual scroll restoration mode Scroll restoration mode does not affect nested iframes but all other scrollable regions. Fixes #349. Also add a note to clarify that manual scroll restoration does not imply position (0,0). Fixes #350. PR #406 --- source | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/source b/source index 06ae89d020f..ae12bb7f80c 100644 --- a/source +++ b/source @@ -82659,7 +82659,9 @@ State: <OUTPUT NAME=I>1</OUTPUT> <INPUT VALUE="Increment" TYPE=BUTTON O

  • If scrollRestoration is "manual" the user agent should not restore the scroll - position for the document, otherwise, it may do so.

    • + position for the Document or any of its scrollable regions, with the exception of + any nested browsing contexts whose scroll restoration is controlled by their own history entry's + scroll restoration mode, otherwise, it may do so.

  • Optionally, update other aspects of the document and its rendering, for instance values of form fields, that the user agent had previously recorded.

    • @@ -82675,6 +82677,11 @@ State: <OUTPUT NAME=I>1</OUTPUT> <INPUT VALUE="Increment" TYPE=BUTTON O data-x="attr-input-type-search">Search state, if the persisted state includes the directionality of user input in such controls.

    +

    Not restoring the scroll position by user agent does not imply that the scroll + position will be left at any particular value (e.g., (0,0)). The actual scroll position depends on + the navigation type and the user agent's particular caching strategy. So web applications should + not assume any particular scroll position but rather should set it to what they want it to be.

    +
    The PopStateEvent interface
    [Constructor(DOMString type, optional PopStateEventInit eventInitDict), Exposed=(Window,Worker)]