I don't yet understand the underlying problem to solve. Could you provide an actual use case please and specific devices related to that use case? Thanks.

In T307851#7911817, @Aklapper wrote:

I don't yet understand the underlying problem to solve. Could you provide an actual use case please and specific devices related to that use case? Thanks.

• I do not want to use Minerva on my laptop!!!!!!
• I do not want to use Vector on my phone!!!!!!!
• I do not want to open up Special:Preferences every time I visit Wikipedia on a device different from the last device I used to visit Wikipedia!!!!!!
• I do not want to append ?useskin=minerva on every page while using my phone!!!!!
• I do not want to create an alternative account for my phone!!!!!!
• I do not want to use the mobile domain which has been established to be worthless for anything but very basic reading!

Hmm.. you're right. Ranting does filter the issue down to the essence.

How I envision this now:

• A "mobile editing mode" is introduced. "Minerva on desktop" should morph into this. This will require Minerva on desktop to get a decent level of support. Bugs like T307848 and T306737 need a level of priority. Take some people from the Reading Web team.
• A "mobile reading mode" is introduced. The mobile domain should morph into this. It will be watered down further, removing all edit functionality. No watch button, no notifications, no page moving. Superclean.
• Neither mode will be on special domains. For the end-user the most sensible way to present them would be as skins. I know that technically they may be more than just skins, but users don't know that, so just present it as skins to them.
• The current detection of mobile devices should (instead of redirecting to the mobile domain) switch to "mobile reading mode" for anons and "mobile editing mode" for users who are logged in.
• And, still, a way to switch skins per session/cookie/etc is needed.

My expectations of the WMF are very limited, so I highly doubt the above will be dealt with (or it'll take 20 years), but while writing this I started to think and maybe, just maybe, this can be accomplished with a userscript/gadget. But there's one hard limitation: the last point, which was the original feature request. It will cause an involuntary page reload whenever the user switches to a device that requires a skin different from the last used skin.

I do not want to use the mobile domain

Why? What are specific reasons that are only related to the domain and not related to any skin being chosen?

(You also may want to check your keyboard, it seems to sometimes print several exclamation marks when pressing that key once.)

It is quite a common feature, for example on Discord you can either have each client (such as Desktop vs mobile apps) have different preferences, or can select to use the same ones. It should be possible to do the same in MediaWiki. I guess it is possible to hack some script detecting the device and applying preferences for it as preferred, but it would make more sense if MW just allowed cookie based preferences overrides (basically as it already allows overrides via get params for skin and language, it should not be too difficult (it would be, but well...) to support the same basing on cookies).

In T307851#7912025, @Aklapper wrote:

I do not want to use the mobile domain

Why? What are specific reasons that are only related to the domain and not related to any skin being chosen?

A link was provided. You have a browser, you can read, you should be able to figure this out.

(You also may want to check your keyboard, it seems to sometimes print several exclamation marks when pressing that key once.)

Seriously, don't. I'll be blunt and hope you'll understand this is not a personal attack: your comments sometimes make me want to pull my hair out. You keep asking "why" when problems are obvious, you don't always fully read task descriptions and ask questions that have already been answered, you tell people they can't vent their frustration because Phabricator etiquette is sacred. I'm not alone in this, I recently saw a user on enwiki say something similar about you. You may not hear it often because the people who feel that way have a tendency of avoiding Phabricator altogether, or at least avoid you to avoid getting blocked.

Unlike you, I am not being paid to act professional. Additional exclamation marks, memes and jokes are the only way I can deal with your comments in a somewhat productive manner, without attacking you. Don't mess this up. I'm not trying to change you, don't you try to change me.

And yeah, there should be an option to permanently disable mobile view. I have requested that on community wishlist in the past, https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2017/Mobile_and_apps/Permanent_opt-out_of_mobile_frontend , but I am not sure if there is a task for that here. Some users have to resolve to a custom script that kinda does that but not immediately: https://meta.wikimedia.org/wiki/User:Vogone/minerva.js

("your comments sometimes make me want to pull my hair out." for the record I have definitely had a comparable feelings sometimes. I am probably more used to try to file more complete tasks now, but I would say Phabricator has an extra hard entry threshold because of this, even when it is difficult to convince people to go file problems on Phabricator in the first place).

The decision about whether to serve the mobile domain happens in Varnish. Varnish has limited technical information - namely the browser user agent and whether the user is not logged in or not so the solution here is constrained greatly. T173527 is the only practical solution to the use cases you raise in T307851#7911945 without a big overhaul of everything.

If you can serve a different skin by appending ?useskin=minerva, why can't you do it with a cookie?

In a nutshell that query string bypasses caching altogether. I suggest you read up on https://wikitech.wikimedia.org/wiki/Caching_overview

This task is impractical.

In T307851#7915959, @Jdlrobson wrote:

If you can serve a different skin by appending ?useskin=minerva, why can't you do it with a cookie?

In a nutshell that query string bypasses caching altogether. I suggest you read up on https://wikitech.wikimedia.org/wiki/Caching_overview

This task is impractical.

Just stop saying it can't be done and start thinking about how it COULD be done.

If I pick another skin in my preferences, you can serve me that skin, right? I don't care how, but clearly caching is fine with that as it demonstrably works.

If I visit a page, a cookie is passed on with my session info. It must be, because I can log in and I'm not logged out when I navigate to another page.

If I log in with the same account on two devices, I get different values for my enwikimwuser-sessionId. (in case of enwiki) If my skin of choice could be tied to that sessionId, I suspect we'd be there.

In T307851#7916457, @AlexisJazz wrote:

Just stop saying it can't be done and start thinking about how it COULD be done.

@AlexisJazz: Please refrain from getting personal and keep things constructive. Thanks.

Comment moved to https://en.wikipedia.org/wiki/User_talk:AKlapper_(WMF)#Please_refrain_from_unconstructive_comments per Phabricator etiquette.

In T307851#7916579, @Aklapper wrote:

In T307851#7916457, @AlexisJazz wrote:

Just stop saying it can't be done and start thinking about how it COULD be done.

@AlexisJazz: Please refrain from getting personal and keep things constructive. Thanks.

This stonewalling isn't helping either, just saying.

In T307851#7911945, @AlexisJazz wrote:

My expectations of the WMF are very limited, so I highly doubt the above will be dealt with (or it'll take 20 years), but while writing this I started to think and maybe, just maybe, this can be accomplished with a userscript/gadget. But there's one hard limitation: the last point, which was the original feature request. It will cause an involuntary page reload whenever the user switches to a device that requires a skin different from the last used skin.

Let's get this out the way first. No one is working on this, no one will be working on this any time soon. It's as simple as that, it falls outside the current priorities, mobile is effectively on hold right now.

• I do not want to use Minerva on my laptop!!!!!!
• I do not want to use Vector on my phone!!!!!!!
• I do not want to open up Special:Preferences every time I visit Wikipedia on a device different from the last device I used to visit Wikipedia!!!!!!
• I do not want to append ?useskin=minerva on every page while using my phone!!!!!
• I do not want to create an alternative account for my phone!!!!!!
• I do not want to use the mobile domain which has been established to be worthless for anything but very basic reading!

Right, so what you want is to use the main domain to use different skins depending on the device being used and remember this.

This requires:

1. Classifying each request with a 'device classifier' (mobile/desktop) and communicate this to the application layer
2. You have to be logged in
3. There need to be two skin settings in the preferences, 1 default for 'desktop' devices, one default for 'mobile' devices. (even though that difference is rather blurry)
4. To override per session, we need a cookie, or we need a data store attached to a session to override preferences and we need to recognise and remember devices.

Short answers:

1. The varnish layer does this already, but this information is currently not passed to the page output of Mediawiki html renderer. It possibly could be, it's just a cookie after all, but this would have to be added/moved from MobileFrontend
2. Things like this cannot work ever for anonymous content. Its a caching nightmare which cannot be solved without massively increasing hardware and setup. Also because of various anti tracking technologies in browsers these days, 'permanent' does not exist for anonymous requests. It's basically a blank slate every single week.
3. This is T173527
4. Cookie seems the only short term option, its lossy but a short term memory likely covers most immediate needs.

How I envision this now:

• A "mobile editing mode" is introduced. "Minerva on desktop" should morph into this. This will require Minerva on desktop to get a decent level of support. Bugs like T307848 and T306737 need a level of priority. Take some people from the Reading Web team.

This is partly why desktop improvements is reworking the skinning system. Finding special cases in Vector and extract them so that other skins get more freedom to deviate without making it a partial implementation. The skinning system is very old and was not designed to be data driven and has 0 provisions for Special page etc. Also Mobile's Advanced mode ties into this a bit I guess, though it doesn't go as far as any of us would want.

It is also why TemplateStyles are so important for communities to adopt, but here too we see that most editors don't know how to write CSS and how to create mobile compatible CSS. Progress has been very slow going honestly. Without Izno doing as much as they are doing, we wouldn't even be close.

• A "mobile reading mode" is introduced. The mobile domain should morph into this. It will be watered down further, removing all edit functionality. No watch button, no notifications, no page moving. Superclean.

This one I don't fully understand.. we'd still want to entice people to edit right ? we want them to read a talk page message if they get send (and if they work) ?

• Neither mode will be on special domains. For the end-user the most sensible way to present them would be as skins. I know that technically they may be more than just skins, but users don't know that, so just present it as skins to them.

I guess this is theoretically possible for logged in users of course. For anon it is a different story, the only way I can come up with is by using separate paths in the url. But.... that seems like a massive undertaking.

• And, still, a way to switch skins per session/cookie/etc is needed.

I'm assuming you want this because you expect that sometimes you want to switch a device that was recognised as mobile to be using desktop and vice versa, have this remembered, but only on that device?

Options:

1. Session: MediaWiki is pretty stateless when it comes to sessions, the application generally only cares if a valid session is in use. I think it should be possible to store additional data in the session, but currently only the session implementation is allowed to store data. We'd likely also want limitations on what can be stored and they would have to be pretty strict because DDoS and the data restrictions can differ per session provider. Additional interfaces would have to be added to access session data from the application layer. It definitely knows nothing about devices. This is also why currently don't have a SessionManager that allows you to see the devices that you are logged in to and giving you an option to log out. There are also significant privacy concerns to storing session information that have to be tackled and checked with privacy policies etc.
2. Cookies (I'm assuming for anon users ?) can be used, but we cannot vary the content based on them. This would cause a caching problem. Adding a query param to every single url based on a cookie also seems fickle to me.
3. Cookies (for logged in users) are an option I guess. Although we try to avoid them in favour of preferences as cookies are not permanent and we generally are moving away from them wherever possible. (also lots of routing complexity involved with cookies)

In the past ServiceWorkers have been suggested as a possible solution for some of this, but I don't think anyone ever spend significant time exploring the possibilities and creating PoCs etc. Maybe someone wants to give that a go ?

In the end... this is a pick your battles problem. Can this be done ? Sure. Should it be done ? Well at what cost is implementing it acceptable ? And is your frustration shared widely enough that it offsets the cost ? Might it be possible that the problem becomes cheaper and simpler if we just wait for some more tech debt to be cleared ? etc etc.
We cannot do everything, choices need to be made. There is no "take some people from the Reading Web team" if each team is "just a few people". My prelim estimate is that all this requires multiple teams (infra, ops, platform and reading), and a significant architectural change of the setup of the WMF websites, carrying significant risks. To do so in the way that you specified, easily months of work would be in play. That seems overly ambitious and dangerous. Smaller goals make more sense and I personally feel that T173527 is a good first goal to tackle.

I sense a frustration with you that MediaWiki is complicated and that WMF is not paying attention to the right things and not innovating quickly enough. As someone who spent 7 years on and off to get a video player replaced, I share your frustration. But this is a big platform with a long support cycle, lots of history and perennially understaffed from the earliest days of its development all through modern days. There is no 'just do things' even if lots of paid staff were to be added.

@TheDJ just thinking out loud: for this particular purpose, maybe we shouldn't even bother (at least not initially) with device detection. If a user wants a different skin on some device/browser they own, let them indicate that themselves on the device in question and serve the chosen skin on that device from then on. The problem to be solved, which will happen when I create a script for this, is an involuntary page reload when opening a Wikimedia site on a device that requires a different skin from the last used device. An involuntary reload several times a day as a user switches between their phone and laptop is not particularly pretty, an involuntary reload once a week as a cookie expires, meh, not a dealbreaker.

This one I don't fully understand.. we'd still want to entice people to edit right ? we want them to read a talk page message if they get send (and if they work) ?

Yes and no, I guess. The vast majority of visitors are readers. You can shove an "edit" button in their face for 50 years and they'll never use it. There's no point in wasting their screen estate. They'll never receive a talk page message, or if they do, it's because they share their IP with someone else.

How exactly these cases would be best handled is something I'm thinking about.

I guess this is theoretically possible for logged in users of course. For anon it is a different story, the only way I can come up with is by using separate paths in the url. But.... that seems like a massive undertaking.

It's not just about domains, IMHO the URL should be the same for everyone. So separate paths in the URL wouldn't help.

I'm assuming you want this because you expect that sometimes you want to switch a device that was recognised as mobile to be using desktop and vice versa, have this remembered, but only on that device?

I know several users who absolutely hate MobileFrontend. Maybe it's acceptable for readers, but for editors it's too crippling. So switching to Minerva by going to the mobile domain is no use in that case. Minerva on the regular domain could be an option, but it's caught in a catch-22: nobody uses it and I can guess why. If you activate it, you'll be stuck with Minerva on your laptop too. And even if you could stand Minerva on your laptop (or you would be willing to jump into your preferences all the time), T306737 seems like it would be quite annoying if you went that route but Jdlrobson unceremoniously closed it as a duplicate of a task it isn't a duplicate of.

"Minerva on desktop" gets no love because "last time we checked Minerva desktop usage was very very low". I mean, no shit Sherlock. I bet its use would skyrocket if this feature request was fulfilled so editors could use it on just their mobile devices.

I sense a frustration with you that MediaWiki is complicated and that WMF is not paying attention to the right things and not innovating quickly enough. As someone who spent 7 years on and off to get a video player replaced, I share your frustration. But this is a big platform with a long support cycle, lots of history and perennially understaffed from the earliest days of its development all through modern days. There is no 'just do things' even if lots of paid staff were to be added.

Thanks, yes, you're pretty much hitting the nail on the head.

It's just that I started thinking about all this, and realized I could nearly "fix" it with a userscript, something I will most likely do, but with one caveat: it's going to cause involuntary page reloads whenever switching to a device that requires a different skin.

Frankly, by limiting all this to two different skins per account (which isn't that bad) and having the user decide by going to the mobile or desktop domain, well.. sure, that would work. And if one of those skins had to be Minerva? Meh, still acceptable. And if that skin was forcibly crippled by MobileFrontend? No. Just no.

In conclusion, if switching skins ain't gonna happen, all of these problems could be resolved by deleting MobileFrontend! And as a crappier workaround (but I'm flexible), if special pages like Special:Diff would be accessible on the mobile domain we could maybe get somewhere. For that particular case, I heard Special:MobileDiff is scheduled to be axed, so that'll be a start.