Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: d860ee92dac3d25b07d1315cc5ad860f54944135
https://github.com/WebKit/WebKit/commit/d860ee92dac3d25b07d1315cc5ad860f54944135
Author: Ahmad Saleem <[email protected]>
Date: 2026-06-29 (Mon, 29 Jun 2026)
Changed paths:
M
LayoutTests/imported/w3c/web-platform-tests/html/browsers/browsing-the-web/navigating-across-documents/refresh/same-document-refresh-expected.txt
M Source/WebCore/loader/NavigationScheduler.cpp
Log Message:
-----------
Meta refresh to URL with different fragment identifier should not be treated
as a page reload
https://bugs.webkit.org/show_bug.cgi?id=314145
rdar://176933795
Reviewed by Chris Dumez.
A refresh (via <meta http-equiv="refresh"> or the HTTP Refresh header) whose
target URL equals the current document's URL ignoring fragments, but adds or
changes the fragment identifier, is a same-document fragment navigation per the
HTML "navigate to a fragment" step [1]. It must not issue a network request or
emit
a new Referer header.
ScheduledRedirect::fire() decided whether the redirect was a "refresh" using
equalIgnoringFragmentIdentifier(), which is true both for an identical URL and
for the same URL with a different fragment. In the latter case it wrongly forced
ResourceRequestCachePolicy::ReloadIgnoringCacheData, which makes
FrameLoader::loadFrameRequest() pick FrameLoadType::Reload. Because
shouldPerformFragmentNavigation() bails out for reloads, WebKit performed a full
network load of the fragment URL instead of an in-document scroll, sending a
fresh Referer (the page's own URL) rather than preserving the original referrer.
Treat the redirect as a same-document fragment navigation only when the
refresh's
own target URL carries a fragment that differs from the current document's
fragment. The decision is made against the target captured at parse time, not
against whatever fragment the user may have scrolled to afterward: a bare
<meta http-equiv="refresh"> with no url= records a fragmentless target and must
always reload (preserving scroll restoration) even if the document's current URL
has since gained a fragment via location.assign('#1'). Only when the target
itself adds or changes the fragment does the redirect flow as a Standard
navigation so shouldPerformFragmentNavigation() performs the same-document
scroll
with the referrer unchanged.
[1]
https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate-fragid-step
*
LayoutTests/imported/w3c/web-platform-tests/html/browsers/browsing-the-web/navigating-across-documents/refresh/same-document-refresh-expected.txt:
Progression.
* Source/WebCore/loader/NavigationScheduler.cpp:
(WebCore::ScheduledRedirect::fire):
Canonical link: https://commits.webkit.org/316001@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
