Tapping "Clear History and Website Data" and after that tapping "Clear History and Data" in the pop-up window, is the way said to clear cache if you have an iPad, which doesn't have the keyboard necessary for the methods described in the above linked guide.

When I logged in on the mobile site first, after clearing data/cache, I was never logged out switching to the desktop site.

After further testing, I found that I was logged out from every Wikipedia I tried, if I, after clearing the data/cache, logged in directly to my watchlist (on the desktop site) of that Wikipedia, i.e. even on Wikipedias I have only visited once before. On the other hand, after logging in directly to my userpage or an article page, there was no problem switching to the mobile site, on any Wikipedia I tried. There was no problem after logging in to the desktop-site watchlist on Commons.

In T253620#6165340, @JohanahoJ wrote:

After further testing, I found that I was logged out from every Wikipedia I tried, if I, after clearing the data/cache, logged in directly to my watchlist (on the desktop site) of that Wikipedia, ...

... and later on tried to switch to the mobile site.

It's not a major problem, but it's still there...

I downloaded Firefox, and it actually worked just fine with that browser.

Back on Safari, the problem remained. I tried changing the "remember me" flag and tried using "safemode=1" and "debug=true". As reported before, it seems to affect all language versions of Wikipedia, but of the different pages I have tested, only the watchlist page.

Perhaps I should have mentioned earlier that I use two-factor authentication. Sorry I missed that!

Sounds like the cross-wiki auto login cookies are not coming through when the login form is configured to direct the user to their watch list. Maybe something is overridden or otherwise not getting called.

@JohanahoJ Can you add more detail to what it means to "directly login to your watch list". Starting with a freshly cleared cache on iPad and seeing the Main Page on en.wikipedia.org desktop site. What do you click etc?

I guess my earlier report of the problem was coloured by how I usually switch to the desktop site as soon as I can, and the mobile site beeing the default site for iPads. After a lot more testing, I see another pattern.

It boiles down to that the problem arises when I switch between mobile and desktop site on the log-in page of any of the Wikimedia projects, and later switch back again.

It doesn't matter if I have cleared the data/cache or not, or wether I switch from mobile to desktop or from desktop to mobile. Commons is sort of an exception in that I get logged in again after a short while, and if I get logged out in the described way on another Wikimedia-project, I have been able to click on a Commons link and get logged in by just reloading the page, as Commons still treats me as being centrally logged in. But I am still logged out when I get back to the other project.

I went back to test Firefox again (still using iPadOS 13.4.1), and found that the same thing actually happened there; after switching between mobile and desktop site, or vice versa, on the log in page, and completing the log in, I was logged out at first switch to the other site (desktop or mobile).

A difference with Firefox, however, is that after being logged out this way, I can tap the go back button (one step back in history) and restore my logged-in status by reloading the page, as I am still recognized as centrally logged in, and after that I can switch between mobile and desktop site without being logged out again. I can't do that with Safari.

Sorry but I still can't understand or help diagnose this issue. As before:

In T253620#6178973, @Krinkle wrote:

[..]
@JohanahoJ Can you add more detail to what it means to "directly login to your watch list"?

Starting with a freshly cleared cache on iPad and seeing the Main Page on en.wikipedia.org desktop site. What do you click etc?

Please describe a specific sequence of actions in terms of button taps etc

(Never mind the watchlist, and I found out that clearing cache or not makes no difference.)

Ok, starting from the Main Page on en.wikipedia.org desktop site:
I tap "Log in" and reach the login page, I tap "Mobile view" and get the mobile view version of the login page, I then enter my user name and password, I tap the "Log in" button and reach the page for entering a verification code from my authentication device, I enter that code and tap "Continue login", reach the Main Page and I am logged in. Then I tap the "Desktop" link, reach the desktop version of the Main Page and I am logged out.

I also get logged out in the same manner if I start from the Main Page on the mobile site, log ut, tap "log in" and after switching to desktop view continue to log in, reach the Main Page and tap the "Mobile view" link.

... and now the problem is no more. I suddenly found this button, in the iPad's "preferences", with an embarassingly obvious title in English: "Prevent Cross-Site Tracking". Apparently, I interpreted the translated version in my own language differently, and switching sites never caused a problem as long as I didn't do it on the login page. I'm so sorry for taking up your time because of this simple mistake.

I'm glad you found a way for now, but note that you should not have to disable cross-site tracking. This kind of tracking can invade privacy, and I think Apple do good by limited or preventing that by default.

It is a problem in our login system that its cookies are not correctly marked through the SameSite semantics.

More about that a https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/.

Ah, thanks for the explaination. I agree, it would be preferable to have the login system work also when cross-site tracking is prevented.

I'm not sure this is related to SameSite. Third-party cookie blocking has been interfering with CentralAuth for a long time. See e.g. T257803: Chrome's "Block third-party cookies" option breaks CentralAuth edge login / autologin.
I don't think we can do much about this for now. We'll have to wait for first-party sets or some other same mechanism of declaring sites as having the same ownership.

In T253620#6305021, @Tgr wrote:

I'm not sure this is related to SameSite. Third-party cookie blocking has been interfering with CentralAuth for a long time.

More specifically, cross-domain SameSite handling is identical in Chrome with third-party cookie-blocking on or off (or at least it was as of 2020 July): T257803#6315123
While I didn't test for Safari, I'd guess it's the same. That means login problems affected by cookie blocking user preferences are not SameSite related.

I'll close this task in favor of T345249: Mitigate phase-out of third-party cookies in CentralAuth which goes into the cookie blocking issues in depth.

Thinking about it more, there are at least two different issues here:

• Autologin doesn't work, probably because Safari blocks third-party cookies.
• Cookies aren't shared between the mobile and desktop domain. This is expected for wikimedia.org wikis like Commons but not expected for Wikipedia. Will see if this is the same issue that causes T257852: CentralAuth edge login and autologin for some Wikimedia domains broken on mobile or needs a separate task.