Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4cb75e05600d142f19d71730baafbe0b7455d8f3
      
https://github.com/WebKit/WebKit/commit/4cb75e05600d142f19d71730baafbe0b7455d8f3
  Author: Ahmad Saleem <[email protected]>
  Date:   2026-08-12 (Wed, 12 Aug 2026)

  Changed paths:
    A 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/scroll-behavior/manual-scroll-clears-target-when-fragment-does-not-exist-expected.txt
    A 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/scroll-behavior/manual-scroll-clears-target-when-fragment-does-not-exist.html
    A 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/scroll-behavior/manual-scroll-clears-target-when-no-fragment-expected.txt
    A 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/scroll-behavior/manual-scroll-clears-target-when-no-fragment.html
   
M
LayoutTests/imported/w3c/web-platform-tests/navigation-api/scroll-behavior/manual-scroll-fragment-does-not-exist-expected.txt
    M Source/WebCore/page/NavigateEvent.cpp

  Log Message:
  -----------
  [Navigation API] navigateEvent.scroll() does not scroll to the beginning of 
the document when the fragment does not exist
https://bugs.webkit.org/show_bug.cgi?id=321498
rdar://184595100

Reviewed by Basuke Suzuki.

Step 4.2 of "process scroll behavior" says that if the document's indicated part
is null, we must scroll to the beginning of the document:
https://flagged.apple.com:443/proxy?t2=Dg2V9G8mJ6&o=aHR0cHM6Ly9odG1sLnNwZWMud2hhdHdnLm9yZy9tdWx0aXBhZ2UvbmF2LWhpc3RvcnktYXBpcy5odG1sI3Byb2Nlc3Mtc2Nyb2xsLWJlaGF2aW9y&emid=acfa0700-d99e-45fc-a539-01d9692739cf&c=11

We already handled the case where the destination URL has no fragment identifier
at all, but when the URL had a fragment that matched no anchor we returned
without scrolling, leaving the scroll
position
untouched.

Instead of duplicating the "is there an anchor?" check, rely on
LocalFrameView::scrollToFragment(), which fails exactly when the document's
indicated part is null, and scroll to the beginning of the document in that 
case,
keeping the existing behavior of restoring the saved scroll position for a
reload. Deferring to scrollToFragment() also stops us from missing an anchor
whose id matches only the percent-decoded fragment, since it tries both forms,
and a fragment holding just a text directive that matched nothing now scrolls to
the beginning of the document as well, matching the spec's behavior of stripping
the directive from the fragment.

Step 1 of "scroll to the fragment" also requires the document's target element 
to
be null when the indicated part is null, otherwise the :target pseudo class 
stays
on the element matched by an earlier fragment. scrollToFragment() takes care of
that via resetScrollAnchor(), so only a destination URL without
a
fragment
identifier needs to clear it explicitly. This matches Chrome.

* 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/scroll-behavior/manual-scroll-clears-target-when-fragment-does-not-exist-expected.txt:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/scroll-behavior/manual-scroll-clears-target-when-fragment-does-not-exist.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/scroll-behavior/manual-scroll-clears-target-when-no-fragment-expected.txt:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/scroll-behavior/manual-scroll-clears-target-when-no-fragment.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/scroll-behavior/manual-scroll-fragment-does-not-exist-expected.txt:
 Progression
* Source/WebCore/page/NavigateEvent.cpp:
(WebCore::NavigateEvent::processScrollBehavior):

Canonical link:
https://flagged.apple.com:443/proxy?t2=Dx8g8S9tu7&o=aHR0cHM6Ly9jb21taXRzLndlYmtpdC5vcmcvMzE5MDY4QG1haW4=&emid=acfa0700-d99e-45fc-a539-01d9692739cf&c=11



To unsubscribe from these emails, change
your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications

Reply via email to