Reader: Fix an issue with anchors not working

[kean]

Fixes CMM-1993: iOS: Footnote links in Reader mode redirect to Reader list instead of target location in post and fixes an issue with scroll(to:) ignoring safe area insets, so that the content would end up under it.

Screen.Recording.2026-03-26.at.3.40.25.PM.mov

[Generated] Details and RCA

Defect Summary

Tapping in-document anchor links (e.g. footnotes) in a Reader post navigates the user to the Discover tab instead of scrolling within the article.

Steps to Reproduce

1. Open any Reader post that contains footnote or anchor links (e.g. 1)
2. Tap on a footnote superscript link
3. Expected: The article scrolls to the footnote at the bottom of the post
4. Actual: The app navigates away to the Reader Discover tab

Root Cause

The issue is caused by a mismatch between the web view's baseURL and the anchor link detection logic in ReaderDetailCoordinator.handle(_:).

Step 1 — baseURL was changed for YouTube embeds.
In a prior change, ReaderWebView.baseURL was set to https://wordpress.com/reader to satisfy Google/YouTube's HTTP referrer requirement. Previously it used the local bundle URL.

Step 2 — Anchor links resolve against baseURL.
When the user taps , WKWebView resolves this relative URL against the baseURL, producing: https://wordpress.com/reader#fn-1

Step 3 — The coordinator fails to recognize it as an in-document anchor.
ReaderDetailCoordinator.handle(_:) checked whether the tapped URL's host+path matched the post's permaLinkURL (e.g. https://example.com/my-post/). Since wordpress.com/reader !=
example.com/my-post/, the check failed.

Step 4 — The URL falls through to the universal link router.
The readerLinkRouter recognizes wordpress.com/reader as a valid Reader route and navigates the user to the Discover tab.

Tap "#fn-1"
→ WKWebView resolves to https://wordpress.com/reader#fn-1
→ handle(_:) checks: does wordpress.com/reader == example.com/my-post? NO
→ Falls through to readerLinkRouter
→ Router matches wordpress.com/reader → navigates to Discover

Fix

Added ReaderWebView.baseURL as a second comparison in the anchor detection logic so that fragment-only links resolved against the web view's base URL are correctly identified as in-document anchors and handled with a scroll instead of navigation.

Secondary Note

The JavaScript anchor fixup code in ReaderWebView.formattedContent(_:) (lines 83–106) is now dead code. It was written to rewrite anchors that started with the bundle URL, but since the baseURL is no longer the bundle URL, it never matches. It is harmless but could be cleaned up in a follow-up.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.

	App Name	Jetpack
	Configuration	Release-Alpha
	Build Number	31804
	Version	PR #25459
	Bundle ID	com.jetpack.alpha
	Commit	5bc4a76
	Installation URL	7cdkvljglfblg

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.

	App Name	WordPress
	Configuration	Release-Alpha
	Build Number	31804
	Version	PR #25459
	Bundle ID	org.wordpress.alpha
	Commit	5bc4a76
	Installation URL	56bke3o2nv0f8

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.