Can I -1 this suggestion? I often want to share a link from the mobile site with someone. It is extremely annoying to manually edit my pasted URL, and worse still if I forget to edit it and the person I'm sending the link to opens the site on desktop and ends up with the mobile site. On the other hand, if my recipient opens a desktop link while they are on mobile, the link is transparently redirected to desktop --- that's a much nicer failure mode. I don't think the extra redirects are that bad for our users, and I'm almost *certain* they have nothing to do with SEO, since Google is getting our page content directly from Parsoid, and Parsoid doesn't "mobile-ify" any of its hrefs.

This appears to be related to fully qualified links in the page. Links to [[articles]] are automatically rewritten for mdot if on mdot already IIRC.

The more sustainable fix in the long run is to serve markup from one domain and vary the response based on device detection or, if present, a cookie that has the user's preference for render. That's a bigger fix, and would need to be staged carefully as it can have surprising consequences for UX, automata, and measurement tools alike. I don't think we're ready to apply that bigger fix just yet, although I'd like to see it eventually. As noted in other places, there is this notion of serving identical HTML for the desktop and mobility use case, although that too requires a lot of analysis.

In Safari mobile, at least, use of the sharesheet action while on mdot yields the canonical (desktop) URL. So for the garden variety sharing case of sharing the current page, sharing of the desktop URL usually does what's considered normal (mobile device gets mobile presentation, desktop user gets desktop presentation; user has pegged cookies

Redirects are an unnecessary tax on the user experience, particularly within higher latency situations. If someone has one second latency for a hot connection, that's literally an extra second of waiting (barring prefetch or intermediary cache scenarios). Demand for the topic that the user is visiting may be inelastic, meaning that the user may be willing to wait. That said, it's nicer to reduce wait time, and furthermore for those for whom demand is elastic (or whose connectivity is suspect), this notches up the experience a bit.

Let's just scrap the whole domain: T214998: RFC: Remove .m. subdomain, serve mobile and desktop variants through the same URL

@Jdlrobson Prod Infrastructure team isn't sure why this was tagged with them, can you give more details? Thanks!

Whoops. I don't know who this should belong to but it needs a product decision - are we scrapping the domain or investing time in T156847 or declining this? Those seem to be the three options with different timelines.