First recognized on Android Samsung Internet.

Does this mean you also experience this on other devices ?

Didn't work there in these days. I'll try now.

@IKhitron: Thanks for reporting this. Please use the bug report form (linked from the top of the task creation page) to create a bug report, and fill in the sections in the template, instead of deleting them. Thanks.

In T352548#9375387, @Aklapper wrote:

@IKhitron: Thanks for reporting this. Please use the bug report form (linked from the top of the task creation page) to create a bug report, and fill in the sections in the template, instead of deleting them. Thanks.

I always use it, and replace placeholders with answers.

So.
1: You are at .. for instance. en.m.wikipedia.org.
2: You are logged in.
3: You click a link to Commons.
4: you are now NOT logged in at commons.m.wikimedia.org ?
5: Now you go back to en.m.wikipedia.org and you are also not logged in on the original website ??? or are you still logged in there ?

If at step 4, where you are on commons.m.wikimedia.org, then click the login button, are you THEN logged in, or do you need to fill in the login information ?

In T352548#9375401, @TheDJ wrote:

So.
1: You are at .. for instance. en.m.wikipedia.org.
2: You are logged in.
3: You click a link to Commons.
4: you are now NOT logged in at commons.m.wikimedia.org ?

For example. I'm on Meta, desktop mode, Global Watchlist. I do not use ".m." at all. I click on some diff in enwiki. It opens logged out in a new tab. F5 does not help. Back to the previous tab on Meta, I'm logged in. Clicking on meta diff in the same Global Watchlist. It opens in a new tab logged in.

5: Now you go back to en.m.wikipedia.org and you are also not logged in on the original website ??? or are you still logged in there ?

Still logged in.

If at step 4, where you are on commons.m.wikimedia.org, then click the login button, are you THEN logged in, or do you need to fill in the login information ?

Just logged in on click, nothing else needed.

PS: I tried in Firefox on Windows three pages, looks fine. I'll work from here for now, and will tell if logging out will happen.
PPS: Other people complained about the same problem in the last days.

Looks like a CentralAuth-related issue - tagging accordingly.

For your information, if you consider a browser-oriented problem. I did not make any update of Android or of the browser in the last few days.

Please check if third-party cookie blocking is enabled for Wikimedia sites - here's a tutorial: https://youtu.be/2zV-8Pj2XJo (a bit old but hopefully it's still the same UI).

Also can you check if the same issue happens on the mobile site?

In T352548#9375421, @IKhitron wrote:

PPS: Other people complained about the same problem in the last days.

Any chance you can link those?

In T352548#9375788, @Tgr wrote:

Please check if third-party cookie blocking is enabled for Wikimedia sites - here's a tutorial: https://youtu.be/2zV-8Pj2XJo (a bit old but hopefully it's still the same UI).

Done, it's not.

In T352548#9375793, @Tgr wrote:

Also can you check if the same issue happens on the mobile site?

Done, it does.

In T352548#9375421, @IKhitron wrote:

PPS: Other people complained about the same problem in the last days.

Any chance you can link those?

It was on Discord.

This happened dozens of times to me in the last three days.

So it started happening on Tuesday? That doesn't really line up with the timing of changes in Wikimedia code/configuration. We deployed rOMWCd2adfe5c30f8: CentralAuth: Fix wikisource.org cookie handling on Monday, but I don't really see that affecting wikis other than Wikisource.

In T352548#9375807, @Tgr wrote:

This happened dozens of times to me in the last three days.

So it started happening on Tuesday? That doesn't really line up with the timing of changes in Wikimedia code/configuration. We deployed rOMWCd2adfe5c30f8: CentralAuth: Fix wikisource.org cookie handling on Monday, but I don't really see that affecting wikis other than Wikisource.

To be more specific, it was fine at Wednesday 2:00 UTC, before I called a day, and broken at Wednesday 10:30 UTC, when I reconnected.

Actually, I'm not sure it was fine at least once since then, I just don't remember.

In T352548#9375822, @IKhitron wrote:

To be more specific, it was fine at Wednesday 2:00 UTC, before I called a day, and broken at Wednesday 10:30 UTC, when I reconnected.

The group1 train sync was at 9:13 UTC so that's more compatible with this being caused by a server-side change.

CentralAuth changes, core changes. I don't see anything particularly SUL-related.

The group1 train sync was at 9:13 UTC so that's more compatible with this being caused by a server-side change.

You mean because Meta is in group 1? Yes, it's possible.

In T352548#9375872, @IKhitron wrote:

You mean because Meta is in group 1? Yes, it's possible.

Either that, or because loginwiki is in also group 1, and it's needed for autologin.

How long takes to login cookie to expire if "stay logged in" box was not checked?

In T352548#9375918, @IKhitron wrote:

How long takes to login cookie to expire if "stay logged in" box was not checked?

30 days, but the corresponding server-side entry expires pretty quickly if there is no user interaction (1 day for the central session and 10 minutes for the local session I think?) and the cookie doesn't have any effect after that.

I'll try to check if the problem happens after 10 minutes of leaving some wiki.

Indeed, looks like the logging out happens after ten minutes of non-working on some wiki.

One more important thing I just found.

1. Open Meta.
2. Click open in a new tab a wiki A link from Meta.
3. Click open in a new tab a wiki B link from Meta.
4. Press F5 on the page from wiki B.
5. Make sure both are logged out.
6. Click log in on the page from wiki A.
7. The page from wiki A is logged in.
8. Go to the page from wiki B.
9. It's still logged out.
10. Press F5 instead of clicking log in.
11. It becames logged in.

Do you check "keep me logged in" when logging in?

Always.

It's extremely worse now.

1. Open some page on other wiki, it's logged out.
2. Click on login, it's logged in.
3. Go for five seconds to other heavy app on the device.
4. Come back to the browser, the wiki page is still in front.
5. It loads from the cache, the page is logged out again.

It sounds to me like your cookies are almost immediately expiring or not being saved at all. As you are not using any adblockers and 3rd party cookie blocking and considering that the timing changed since the issue first started for you, I wonder if the clock of your device is set properly. Maybe it is not set to sync automatically with timeservers ?

Another option is that the storage that the domain is allowed to use is completely filled up and that this accidentally also blocks updates to cookies from being saved ???
That would be strange, but as this is the Samsung browser, it's not unfathomable that it is doing some things that are outside the expectations....

I'm thinking if there is an easy way for you to empty local storage (we should really have a hidden page for this in mediawiki ... )

In T352548#9390377, @TheDJ wrote:

It sounds to me like your cookies are almost immediately expiring or not being saved at all.

Me too. But it was fine until days ago. It does not happen for non wiki sites. It does not happen with meta itself.

As you are not using any adblockers and 3rd party cookie blocking and considering that the timing changed since the issue first started for you, I wonder if the clock of your device is set properly. Maybe it is not set to sync automatically with timeservers ?

No blockers, the clock is fine, nothing changed on device, I make app updates on Saturday eves.

Another option is that the storage that the domain is allowed to use is completely filled up and that this accidentally also blocks updates to cookies from being saved ???

I have a lot of place on the disk, can there be other restrictions?

That would be strange, but as this is the Samsung browser, it's not unfathomable that it is doing some things that are outside the expectations....

I'm thinking if there is an easy way for you to empty local storage (we should really have a hidden page for this in mediawiki ... )

Maybe some js script I can run using global.js?

@IKhitron if this is relatively easy for you to reproduce on demand, then I thing the best thing to do would be to reproduce it with WikimediaDebug installed and the "verbose log" option enabled, and provide an approximate timestamp.

In T352548#9390377, @TheDJ wrote:

I'm thinking if there is an easy way for you to empty local storage (we should really have a hidden page for this in mediawiki ... )

It's not really easy because local storage is per origin and we have like a thosand of those, but T179752: Clear site data on MediaWiki log out is a related task which seems doable if at the cost of some collateral damage (you can't control exactly what data to clear).

You do remember it's an Android problem?

Doesn't Samsung Internet enable browser extensions?

T350094: Enable verbose logging without installing the WikimediaDebug extension was my idea of how to enable logging on mobile, but that will take a while.

In T352548#9398486, @Tgr wrote:

Doesn't Samsung Internet enable browser extensions?

Yep, eight of them in entire world. Nothing complicated. And it even does not have a console.

Well, enough time later I can say that the problem disappeared a second after the consequent deployment. Unless somebody else continues experiencing it, I would suggest to close the task.