This should probably be merged into T60425: Mobile site does not automatically redirect to desktop version (and not possible to use browser "use desktop view") and rescope that task to just the parenthetical "not possible to use browser "use desktop view"" given the m. work going on. And by "not possible" we can mean any of "doesn't work the basic way / doesn't work people might expect / some other thing TBD" as with your "I think it becomes more important we define behavior for this."

Checked the steps on iPhone 11 (iOS 18) - the Chrome option "Request desktop site" doesn't do enything.

Steps:
(1) on iPhone Chrome visit wikitech.wikimedia.org - Main page in incognito Tab

(2) the page is displayed in mobile mode

(3) click on the three dots to display options - click on the toggle "Request Desktop site"

(4) the page won't switch to the Desktop mode

The issue here: the toggle "Request Desktop site" should work just as the option "Desktop" in the footer menu?

Much more interesting issue happens when visiting an article
Steps:

• after the (1)-(2) steps above, click on Random to go to an article
• an article will be displayed in mobile mode
• click on the tree dots on the toggle "Request Desktop site"
• a new article will be displayed in a mobile mode

The footer options Desktop/Mobile work as expected for the steps above.

When switching with "Request Desktop site" and back works:

• I checked without incognito tab - and got the same results as in https://phabricator.wikimedia.org/T403866#11159939

Summary:

• The "Request desktop site" button in Safari Mobile works both with the old m-dot setup and in the new unified setup, because it seems to magically tie itself to our footer opt-out/opt-in links.

• "Desktop site" button Chrome Mobile doesn't work at all in the old m-dot setup today. Our m-dot URLs consistently serve the same response regardless of user agent string.

• With the new setup "Desktop site" starts to sometimes work in Chrome Mobile, which is arguably an improvement, but it is inconsistent and unreliable. This is because Chrome Mobile tries to re-use it local browser cache for the current page. If the Last-Modified header is the same (i.e. the article hasn't been edited), then Chrome re-uses it. This seems silly because it knows the user agent changed, and the whole purpose of this feature is to get a different response. Firefox and Safari treat it more like a "hard reload" and are unaffected.

• This isn't about Wikitech vs test.wikipedia. It's a general race condition specific to Chrome on Android that depends on
  • 1) your browser cache,
  • 2) whether you arrived at the page via a redirect,
  • 3) whether the page is warmed up in your nearest WMF CDN cluster,
  • 4) whether the article was purged/edited between your two switch attempts,
  • 5) whether your cookies changed between the two toggles. The browser may only re-uses browser caches if your cookies remained the same. If you gained or changed any cookie, doesn't matter which one, then your browser won't re-use the browser cache. This explains why this works best on a fresh device/emulation session, becuase the first view will be on mobile and you have no pre-existing cookies. That first mobile view then loads EventLogging/mw.user to compute a session ID, or maybe you get a banner, which plants a cookie and thus clears your browser cache for this site. This means the first switch to desktop works and you get a fresh copy. During the desktop view no cookies are added or changed, so the second toggle no-ops because the browser cache is eligible.

This seems like a Chrome bug. We may be able to workaround it. I don't think this is a blocker given that it isn't a regression. However, we're waiting for other work so we may as well try to fix it.

Research

I think this is a race or cache condition that could happen on any site. Sites with unified mobile routing enabled are all configured the same way, and I still can't reproduce it with wikitech.wikimedia.org using the same Chrome version and Android model in BrowserStack.

But, I tested test.wikipedia.org as well, and while it didn't happen there for Jon, it did for me. However, it couldn't reproduce it again 5 minutes later.

I found a few things:

1. Chrome on Android reloads the original URL that started the navigation, not the current URL.

This is actually why it sometimes works even in the old m-style setup. When you open a link like en.wikipedia.org/wiki/Banana on mobile, we redirect to m-dot, which in turn serves the same response regardless of user agent (the old m-dot setup doesn't have a redirect for desktop user agents). But, when you ask Chrome on Android for the desktop version in this scenario, it actually loads the original URL again, which happens to be the desktop-to-mobile redirect, and this time our CDN can respond with a page instead of a redirect, so it "works".

When the link you follow is already m-dot, or if you search/click around before switching, then this doesn't work. It would simply reload the same m-dot URL with a desktop user-agent, and receive the same mobile version. The status quo is that "Desktop site" in Chrome Mobile doesn't work on most mobile pageviews.

2. Browsers may send an If-Modified-Since request header based on the article's Last Modified response header.

For the old m-dot URLs, when the switch doesn't work it's simply because the m-dot URLs respond the same way regardless of user agnet.

For the wikis with unified mobile routing enabled, the first switch now sometimes returns the expected desktop mode and sometimes renders the same again, and the second switch likewise also sometimes returns the expected mobile mode, and sometimes the same desktop render again.

What you see in the cases where the switch doesn't do anything, is that the browser is rendering its local local browser cache.

I've verifed via devtools and server-side logs from Varnish that there isn't a cache corruption or something we're mixing up on our end.

Chrome is taking the Last-Modified value from the desktop pageview, and then making a seemingly normal repeat visit with a mobile user agent, asking if the page was modified or whether it can use its cached copy. What Chrome isn't saying. is that its cached copy was originally requested with a different user agent. It seems Firefox and Safari don't try to use the browser cache in their equivalent scenario. Chrome is trying to re-use its browser cache, in a way that we can't distinguish from a normal repeat visit to the same article from the same device and user agent.

• Chrome Mobile UA > GET test.wikipedia.org/ > HTTP 301
• Chrome Mobile UA > GET test.wikipedia.org/wiki/Main_Page > HTTP 200 OK (mobile version)
• Chrome Desktop UA > GET test.wikipedia.org/ > HTTP 301
• Chrome Desktop UA -> GET test.wikipedia.org/wiki/Main_Page -> HTTP 200 OK (cache miss, desktop version)

In this scenario, requesting the desktop version worked, and then switching back also worked.

Here is an example where I experienced the same thing as @Etonkovidova, where neither of the switches work:

• Chrome Mobile UA > GET www.mediawiki.org/wiki/ResourceLoader/Architecture > HTTP 200 OK (mobile version)
• Chrome Desktop UA > GET www.mediawiki.org/wiki/ResourceLoader/Architecture > HTTP 304 Not Modified
• Chrome Mobile UA > GET www.mediawiki.org/wiki/ResourceLoader/Architecture > HTTP 304 Not Modified

krinkle@stat1011:~$ kafkacat -C -b kafka-jumbo1013.eqiad.wmnet:9092 -o -100000 -t webrequest_frontend_text | fgrep '"cp3066.esams.wmnet","ip":"194.165.164.22'
…

# Mobile UA > GET test.wikipedia.org/ > HTTP 301
{…,
 "cache_status":"miss",
 "content_type":"text/html; charset=UTF-8",…,
 "http_method":"GET",
 "http_status":"301",
 "hostname":"cp3066.esams.wmnet","ip":"194.165.164.225",
 "dt":"2025-09-10T03:23:11Z",…,
 "uri_host":"test.wikipedia.org","uri_path":"/","uri_query":"",
 "user_agent":"Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Mobile Safari/537.36",
 "x_analytics":"…;ismobile=1;…",
 "x_cache":"cp3066 miss, cp3066 miss",…
}
# Mobile UA > GET test.wikipedia.org/wiki/Main_Page > HTTP 200 OK (mobile version)
{…,
 "cache_status":"hit-front",
 "content_type":"text/html; charset=UTF-8",…,
 "http_method":"GET",
 "http_status":"200",
 "hostname":"cp3066.esams.wmnet","ip":"194.165.164.225",
 "dt":"2025-09-10T03:23:11Z",…,
 "referer":"-",…,
 "uri_host":"test.wikipedia.org","uri_path":"/wiki/Main_Page","uri_query":"",
 "user_agent":"Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Mobile Safari/537.36",
 "x_analytics":"ns=0;page_id=11791;…;include_pv=1;…;ismobile=1;…",
 "x_cache":"cp3066 miss, cp3066 hit/1",…
}
# Desktop UA > GET test.wikipedia.org/ > HTTP 301
{…,
 "cache_status":"hit-front",
 "content_type":"text/html; charset=UTF-8",…,
 "http_method":"GET",
 "http_status":"301",
 "hostname":"cp3066.esams.wmnet","ip":"194.165.164.225",
 "dt":"2025-09-10T03:23:17Z",…,
 "referer":"-",…,
 "uri_host":"test.wikipedia.org","uri_path":"/","uri_query":"",
 "user_agent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36",
 "x_analytics":"…",
 "x_cache":"cp3066 miss, cp3066 hit/1",…
}
# Desktop UA -> GET test.wikipedia.org/wiki/Main_Page -> HTTP 200 OK
{…,
 "cache_status":"miss",
 "content_type":"text/html; charset=UTF-8",…,
 "http_method":"GET",
 "http_status":"200",
 "hostname":"cp3066.esams.wmnet","ip":"194.165.164.225",
 "dt":"2025-09-10T03:23:17Z",…,
 "referer":"-",…,
 "uri_host":"test.wikipedia.org","uri_path":"/wiki/Main_Page","uri_query":"",
 "user_agent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36",
 "x_analytics":"…;include_pv=1;…",
 "x_cache":"cp3066 miss, cp3066 miss",…
}

# Mobile UA -> GET / -> HTTP 301
{…,
 "cache_status":"hit-front",
 "content_type":"text/html; charset=UTF-8",…,
 "http_method":"GET",
 "http_status":"301",
 "hostname":"cp3066.esams.wmnet","ip":"194.165.164.225",
 "dt":"2025-09-10T03:23:23Z",…,
 "referer":"-",…,
 "uri_host":"test.wikipedia.org","uri_path":"/","uri_query":"",
 "user_agent":"Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Mobile Safari/537.36",
 "x_analytics":"…;ismobile=1;…",
 "x_cache":"cp3066 miss, cp3066 hit/2",…
}

# Mobile UA -> GET /wiki/Main_Page -> HTTP 304 Not Modified
{…,
 "cache_status":"hit-front",
 "content_type":"text/html; charset=UTF-8",…,
 "http_method":"GET",
 "http_status":"304",
 "hostname":"cp3066.esams.wmnet","ip":"194.165.164.225",
 "dt":"2025-09-10T03:23:23Z",…,
 "referer":"-",…,
 "uri_host":"test.wikipedia.org","uri_path":"/wiki/Main_Page","uri_query":"",
 "user_agent":"Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Mobile Safari/537.36",
 "x_analytics":"ns=0;page_id=11791;…;ismobile=1;…",
 "x_cache":"cp3066 miss, cp3066 hit/2",…
}

krinkle@cp3066:~$ sudo varnishlog -c -n frontend -i ReqUrl,ReqHeader,RespHeader -q "ReqHeader eq 'Host: test.wikipedia.org'"'"
*   << Request  >> 249854257
-   ReqURL         /wiki/Main_Page
-   ReqHeader      user-agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Mobile Safari/537.36
-   ReqHeader      if-modified-since: Tue, 09 Sep 2025 14:26:12 GMT
-   ReqHeader      …
-   ReqHeader      Host: test.wikipedia.org
-   ReqURL         /wiki/Main_Page
-   ReqHeader      X-Subdomain: M
-   ReqHeader      X-CDIS: hit/9
-   RespHeader     server: mw-web.eqiad.main-cd8dfd775-pm7mz
-   RespHeader     x-analytics: ns=0;page_id=11791;rev_id=585017
-   RespHeader     vary: Accept-Encoding,X-Subdomain,Cookie,Authorization,X-Experiment-Enrollments
-   RespHeader     cache-control: s-maxage=1209600, must-revalidate, max-age=0
…
-   RespHeader     last-modified: Tue, 09 Sep 2025 14:26:12 GMT
-   RespHeader     X-Cache-Int: cp3066 miss
-   RespHeader     Age: 8964
-   RespHeader     Vary: Accept-Encoding,X-Subdomain,Cookie,Authorization
-   RespHeader     X-Cache: cp3066 miss, cp3066 hit/9
…
-   RespHeader     Cache-Control: private, s-maxage=0, max-age=0, must-revalidate, no-transform

*   << Request  >> 308089130
-   ReqURL         /wiki/Main_Page
-   ReqHeader      user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36
-   ReqHeader      sec-fetch-mode: navigate
-   ReqHeader      if-modified-since: Tue, 09 Sep 2025 14:26:12 GMT
…
-   ReqHeader      Host: test.wikipedia.org
-   ReqURL         /wiki/Main_Page
…
-   ReqHeader      X-CDIS: hit/1
-   RespHeader     server: mw-web.eqiad.main-cd8dfd775-cbtln
-   RespHeader     x-analytics: ns=0;page_id=11791;rev_id=585017
-   RespHeader     vary: Accept-Encoding,X-Subdomain,Cookie,Authorization,X-Experiment-Enrollments
-   RespHeader     cache-control: s-maxage=1209600, must-revalidate, max-age=0
…
-   RespHeader     last-modified: Tue, 09 Sep 2025 14:26:12 GMT
…
-   RespHeader     Age: 1556
-   RespHeader     Vary: Accept-Encoding,X-Subdomain,Cookie,Authorization
-   RespHeader     X-Cache: cp3066 miss, cp3066 hit/1
…
-   RespHeader     Cache-Control: private, s-maxage=0, max-age=0, must-revalidate, no-transform

$ sudo varnishlog -c -n frontend -i ReqUrl,ReqHeader,RespHeader -q "ReqUrl ~ '/wiki/ResourceLoader' and ReqHeader eq 'Host: www.mediawiki.org'"'"
*   << Request  >> 290936453
-   ReqURL         /wiki/ResourceLoader/Architecture
-   ReqHeader      user-agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Mobile Safari/537.36
-   ReqHeader      sec-fetch-mode: navigate
-   ReqHeader      Host: www.mediawiki.org
-   ReqURL         /wiki/ResourceLoader/Architecture
-   ReqHeader      X-Subdomain: M
-   ReqHeader      X-CDIS: hit/1
-   RespHeader     server: mw-web.eqiad.main-cd8dfd775-btrc8
-   RespHeader     x-analytics: ns=0;page_id=89983;rev_id=7580718
-   RespHeader     vary: Accept-Encoding,X-Subdomain,Cookie,Authorization,X-Experiment-Enrollments
-   RespHeader     cache-control: s-maxage=1209600, must-revalidate, max-age=0
…
-   RespHeader     last-modified: Thu, 04 Sep 2025 03:11:27 GMT
-   RespHeader     X-Cache-Int: cp3066 miss
-   RespHeader     Age: 36
-   RespHeader     Vary: Accept-Encoding,X-Subdomain,Cookie,Authorization
-   RespHeader     X-Cache: cp3066 miss, cp3066 hit/1
…
-   RespHeader     X-Analytics: ns=0;page_id=89983;…;ismobile=1;…
-   RespHeader     Cache-Control: private, s-maxage=0, max-age=0, must-revalidate, no-transform
-   RespHeader     Content-Length: 37166
-   RespHeader     Connection: keep-alive

*   << Request  >> 291003450
-   ReqURL         /wiki/ResourceLoader/Architecture
-   ReqHeader      user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36
-   ReqHeader      sec-fetch-mode: navigate
-   ReqHeader      if-modified-since: Thu, 04 Sep 2025 03:11:27 GMT
-   ReqHeader      host: www.mediawiki.org
…
-   ReqURL         /wiki/ResourceLoader/Architecture
-   ReqHeader      X-CDIS: miss
-   RespHeader     server: mw-web.eqiad.main-cd8dfd775-vm248
-   RespHeader     x-analytics: ns=0;page_id=89983;rev_id=7580718
…
-   RespHeader     vary: Accept-Encoding,X-Subdomain,Cookie,Authorization,X-Experiment-Enrollments
-   RespHeader     cache-control: s-maxage=1209600, must-revalidate, max-age=0
-   RespHeader     last-modified: Thu, 04 Sep 2025 03:11:27 GMT
…
-   RespHeader     Age: 0
-   RespHeader     Vary: Accept-Encoding,X-Subdomain,Cookie,Authorization
-   RespHeader     X-Cache: cp3066 hit, cp3066 miss
…
-   RespHeader     X-Analytics: ns=0;page_id=89983;rev_id=7580718;…
-   RespHeader     Cache-Control: private, s-maxage=0, max-age=0, must-revalidate, no-transform
-   RespHeader     Connection: keep-alive

*   << Request  >> 286879546
-   ReqURL         /wiki/ResourceLoader/Architecture
-   ReqHeader      user-agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Mobile Safari/537.36
-   ReqHeader      sec-fetch-mode: navigate
-   ReqHeader      if-modified-since: Thu, 04 Sep 2025 03:11:27 GMT
-   ReqHeader      Host: www.mediawiki.org
-   ReqURL         /wiki/ResourceLoader/Architecture
-   ReqHeader      X-Subdomain: M
-   ReqHeader      X-CDIS: hit/2
-   RespHeader     server: mw-web.eqiad.main-cd8dfd775-btrc8
-   RespHeader     x-analytics: ns=0;page_id=89983;rev_id=7580718
…

-   RespHeader     vary: Accept-Encoding,X-Subdomain,Cookie,Authorization,X-Experiment-Enrollments
-   RespHeader     cache-control: s-maxage=1209600, must-revalidate, max-age=0
…
-   RespHeader     last-modified: Thu, 04 Sep 2025 03:11:27 GMT
…
-   RespHeader     Age: 51
-   RespHeader     Vary: Accept-Encoding,X-Subdomain,Cookie,Authorization
-   RespHeader     X-Cache: cp3066 miss, cp3066 hit/2
…
-   RespHeader     X-Analytics: ns=0;page_id=89983;…;ismobile=1;…
-   RespHeader     Cache-Control: private, s-maxage=0, max-age=0, must-revalidate, no-transform
-   RespHeader     Connection: keep-alive
…

Safari has something different going on entirely. The Safari's "Request desktop website" button appears to have proprietary and undocumented logic hardcoded specifically for MediaWiki-based sites, and sets our internal mobileaction parameter on the switching request. This is reproducible on test.wikipedia.org, en.wikipedia.org, en.wikivoyage.org (one of our newest families), as well as on third-party sites like meta.miraheze.org. I confirmed that it does not try to set this parameter when switching on www.wikimedia.org (under our domain, but not a wiki), and not on www.wikifunctions.org (a wiki but no MF installed). My guess is that they're looking for #footer-places-desktop-toggle or #mw-mf-display-toggle in the DOM to find the "Desktop" link.

And indeed, when I created the following page up on https://people.wikimedia.org/~krinkle/T403866.html and used the native "Request desktop site" button, it went to the Miraheze address. Fascinating. Anyway, that explains why it "works" in Safari, albeit in an entirely different way that we don't control, but works fine — and better right now than Chrome on Android.

<!DOCTYPE html>
So
<li id="footer-places-desktop-toggle"><a id="mw-mf-display-toggle" href="https://meta.miraheze.org/wiki/FAQ?mobileaction=toggle_view_desktop" data-event-name="switch_to_desktop">Desktop</a></li>

Back to the Chrome issue, this basically comes down to HTTP cache semantics, very similar to how you're interpret cache eligibility and matching between MediaWiki and the CDN, or between the browser and e.g. a ServiceWorker via the Cache API in JavaScript.

For Chrome to not consider its browser cache, the cache object would need to "Vary" by User-Agent. This is a non-starter for our application stack in general, as it would decimate our CDN performance and cache hit rate. But.. it might be feasible to inject this at the edge only for external use, similar to how we inject Cache-Control: private, s-maxage=0, max-age=0, must-revalidate, no-transform already.

See also:

• T33639: MediaWiki should use ETags instead of Last-Modified and the Logged out cookie hack
• T142542: LoggedOut cookie not set anymore
• T295619: Cookie value sent in HTTP requests changes too frequently

Change #1187464 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/puppet@production] varnish: Add "Vary: User-Agent" during delivery of pageviews

https://gerrit.wikimedia.org/r/1187464

The above patch is now live in the Beta Cluster for all its wikis. It works reliably for me in Safari on iOS and Chrome on Android.

@Etonkovidova Would you mind confirming it as well? I want to make sure my experience wasn't a fluke.

By the way, because this is an infrastructure patch (via SRE) rather than MediaWiki, it means it does not have a train to "ride". Instead, I have cherry-picked this in unmerged state from Gerrit to the servers that control the Beta Cluster. When SRE deploy it to production (next Monday), they will merge it in Gerrit. For infrastructure changes like these, merging in Gerrit is roughly equal to immediate deployment everywhere.

In T403866#11176278, @Krinkle wrote:

The above patch is now live in the Beta Cluster for all its wikis. It works reliably for me in Safari on iOS and Chrome on Android.

@Etonkovidova Would you mind confirming it as well? I want to make sure my experience wasn't a fluke.

By the way, because this is an infrastructure patch (via SRE) rather than MediaWiki, it means it does not have a train to "ride". Instead, I have cherry-picked this in unmerged state from Gerrit to the servers that control the Beta Cluster. When SRE deploy it to production (next Monday), they will merge it in Gerrit. For infrastructure changes like these, merging in Gerrit is roughly equal to immediate deployment everywhere.

Thanks, @Krinkle! It works (it's still possible to create race/cache condition, but it's not impactful) . As soon it's in prod, I'll re-check.

Change #1187464 merged by BCornwall:

[operations/puppet@production] varnish: Add "Vary: User-Agent" during delivery of pageviews

https://gerrit.wikimedia.org/r/1187464

The change has been deployed, @Etonkovidova.

Similar to the previous change, due to the sensitivity of global CDN configuration changes, I have done basic testing in the Beta Cluster (pre-merge via cherry pick), and during the deployment on a canary host. The test I used is:

1. Visit testwiki or mediawiki.org in Chrome/Android and Safari/iPhone, click an article, then request desktop.
2. Going to another page (i.e. talk page, or view history), and then requesting (back) to mobile.
3. Viewing a URL like https://test.wikipedia.org/w/load.php?modules=site directly in desktop Safari, and comparing it to https://test.m.wikipedia.org/w/load.php?modules=site (mobile domain), and observing the difference. Then, switch desktop Safari to use a mobile user-agent string (Develop menu) and refresh the first tab to confirm it now shows the same JS response as the m-dot version.

I can confirm the fix on my side!

FWIW this is actually a delightful new feature - as it means we no longer have to scroll down to the footer to toggle modes for the small percentage of content which isn't quite optimized for mobile.

Change #1191543 had a related patch set uploaded (by Krinkle; author: Krinkle):

[operations/puppet@production] varnish: Enable Vary:User-Agent on all wikis

https://gerrit.wikimedia.org/r/1191543

Change #1191543 merged by BCornwall:

[operations/puppet@production] varnish: Enable Vary:User-Agent on all wikis

https://gerrit.wikimedia.org/r/1191543