RESOLVED FIXED313542
Inconsistent customUserAgent behaviours with WKWebView when 302-server-side redirect link is tapped vs loaded directly
https://bugs.webkit.org/show_bug.cgi?id=313542
Summary Inconsistent customUserAgent behaviours with WKWebView when 302-server-side r...
steaps.4
Reported 2026-04-28 07:28:38 PDT
Created attachment 479352 [details] A small sample project containing a WKWebView and 2 links to load that show different behaviours of 302-redirects and customUserAgent property When updating a WKWebView customUserAgent in WKNavigationDelegate method ``` optional func webView( _ webView: WKWebView, decidePolicyFor navigationAction: WKNavigationAction, decisionHandler: @escaping @MainActor @Sendable (WKNavigationActionPolicy) -> Void )``` The URLRequest header for `User-Agent` field is only modified when a 302-server-side redirect link is tapped in the web view. If the WKWebView loads the same URL/URLRequest directly, and the customUserAgent is updated the same way in webView(_:decidePolicyFor:decisionHandler:), then WKWebView does NOT update the header as expected before sending the request. I attached a sample project that shows the difference between the two loads. First, build & run the project. The WKWebView will load https://test-website-a.pages.dev/server-redirect/. Tap `Navigate to header inspector via server-side 302 redirect` link. You will see `Desktop` in the `user-agent` field for `HTTP Request Headers` section. Next, comment out line 37 in ViewController.swift. Uncomment line 40 for loading `https://test-website-a.pages.dev/server-redirect/go`. Rebuild & run the project. You will see `Mobile` in the `user-agent` field for `HTTP Request Headers` section despite loading the same link as above. Both of these tests load the same `https://test-website-a.pages.dev/server-redirect/go` link, which is a 302-server-side redirect to `https://test-website-b.pages.dev/server-redirect/headers` but the `User-Agent` field of the HTTP Request Header only updates correctly when the link is tapped on.
Attachments
A small sample project containing a WKWebView and 2 links to load that show different behaviours of 302-redirects and customUserAgent property (55.43 KB, application/zip)
2026-04-28 07:28 PDT, steaps.4
no flags
steaps.4
Comment 1 2026-04-28 08:10:09 PDT
This is also an issue when using the `WKWebpagePreferences` private `_customUserAgent` / `setCustomUserAgent:` property/setter when updating the `WKWebpagePreferences` in the WKNavigationDelegate method ``` optional func webView( _ webView: WKWebView, decidePolicyFor navigationAction: WKNavigationAction, preferences: WKWebpagePreferences, decisionHandler: @escaping @MainActor @Sendable (WKNavigationActionPolicy, WKWebpagePreferences) -> Void )``` For example, replacing the existing WKNavigationDelegate method in the sample project with: ``` func webView(_ webView: WKWebView, decidePolicyFor navigationAction: WKNavigationAction, preferences: WKWebpagePreferences, decisionHandler: @escaping @MainActor (WKNavigationActionPolicy, WKWebpagePreferences) -> Void) { if navigationAction.request.url?.host() == "test-website-b.pages.dev" { if preferences.responds(to: Selector(("_setCustomUserAgent:"))) { preferences.perform(Selector(("_setCustomUserAgent:")), with: "Desktop") } } decisionHandler(.allow, preferences) } ``` Will reproduce the same bug.
Radar WebKit Bug Importer
Comment 2 2026-05-05 07:29:10 PDT
Brent Fulgham
Comment 3 2026-05-11 20:26:15 PDT
Do you feel like this is something that has regressed recently? If so, can you share an OS version where it worked as expected? That can help us try to isolate what changed, and how to repair this.
steaps.4
Comment 4 2026-05-11 20:54:25 PDT
No I don't believe it's regressed too recently, it reproduces on iOS 17.0 simulators. We've just noticed it recently after some logic changes relating to user agent in our app with some sites using the unexpected user agent from the request headers.
Basuke Suzuki
Comment 5 2026-05-12 14:57:13 PDT
EWS
Comment 6 2026-05-12 21:47:12 PDT
Committed 313127@main (9a2a1a1b6932): <https://commits.webkit.org/313127@main> Reviewed commits have been landed. Closing PR #64787 and removing active labels.
Note You need to log in before you can comment on or make changes to this bug.