Works for me (well, top-level autologin works, so I couldn't test those exact steps).
Sounds like a cookie conflict. Unfortunately I am not really sure how to check your cookies in Firefox, the developer toolbar doesn't seem to go a good job of it.

I know how to. Which cookies should I check for?

This looks similar to T350695. When I visit https://wikisource.org/, my browser sends two sets of CentralAuth cookies, just like T350695#9313140:

I'm not currently experiencing the problem, but if one of those sessions expired, I probably would.

At least on en.wikisource, I only have 1 session ID though. These are present even when not logged in:

In T351685#9349115, @matmarex wrote:

This looks similar to T350695. When I visit https://wikisource.org/, my browser sends two sets of CentralAuth cookies, just like T350695#9313140:

I don't get why. We have

'wikisource' => '.wikisource.org',
'sourceswiki' => '.wikisource.org',

in the $wmgCentralAuthCookieDomain config. At least in a debug shell, it works as expected.

I guess we can add wikisources to rOMWCdf0dafd48dce: CentralAuth: Clear domain cookie when setting non-domain cookie and that will either make it better or make it worse.

In T351685#9353656, @aliu wrote:

Multilingual wikisource does in fact give me multiple things, though the first two are identical save for name (the first one is named centralauth_ss0-Token while the second one is just named centralauth_Token)

Typically what we are looking for with session loss problems is two cookies with identical name but different domain.

Same here (cannot save a edit on en.wikisource due to being logged in and out in successive requests)

In T351685#9353656, @aliu wrote:

Multilingual wikisource does in fact give me multiple things, though the first two are identical save for name (the first one is named centralauth_ss0-Token while the second one is just named centralauth_Token)

Typically what we are looking for with session loss problems is two cookies with identical name but different domain.

@Tgr I appear to have two cookies called centralauth_Session one with a domain .wikisource.org and another with a domain wikisource.org (This is Chrome 119.0.6045.105 (Official Build) (64-bit))

Change 976864 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[operations/mediawiki-config@master] CentralAuth: Fix wikisource.org cookie handling

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

I'm only seeing this happen when I'm loading resources from wikisource.org on en.wikisource.org. In my case that was only the InterWikiTransclusion gadget, and with that turned off I'm no longer getting logged out on enwikisource.

I'm pretty sure I haven't enabled any gadgets on Wikisource.

In T351685#9356089, @Samwilson wrote:

I'm only seeing this happen when I'm loading resources from wikisource.org on en.wikisource.org. In my case that was only the InterWikiTransclusion gadget, and with that turned off I'm no longer getting logged out on enwikisource.

I agree, I think that might be the culprit, we should ask on scriptorium to disable it especially since it is enabled by default :)

I've disabled the gadget on enWS, but we have multiple gadgets that crossload code from other projects (HotCat from Commons, Wikidata Framework from an obfuscated code blob in user-space on ruWS, Popups from enWP, etc.) and across the Wikisourcen multiple languages crossload scripts from oldwikisource.

I also see nothing in MediaWiki:InterWikiTransclusion.js that should be able to trigger the behaviour described, so it's not the cause and disabling it can only be a temporary measure.

Hmm, logging in works now.

The interlingual Wikisource's login still doesn't work.

In T351685#9356844, @Xover wrote:

I've disabled the gadget on enWS, but we have multiple gadgets that crossload code from other projects (HotCat from Commons, Wikidata Framework from an obfuscated code blob in user-space on ruWS, Popups from enWP, etc.) and across the Wikisourcen multiple languages crossload scripts from oldwikisource.

I also see nothing in MediaWiki:InterWikiTransclusion.js that should be able to trigger the behaviour described, so it's not the cause and disabling it can only be a temporary measure.

The gadget is loading code from wikisource.org which is causing the session cookie conflicts mentioned, this should be temporary untill the patch that Tgr has proposed has been merged and deployed

Yeah it's only the cross-loading from wikisource.org that's the concern, the others (Commons etc.) should be fine.

In T351685#9353785, @Tgr wrote:

In T351685#9349115, @matmarex wrote:

This looks similar to T350695. When I visit https://wikisource.org/, my browser sends two sets of CentralAuth cookies, just like T350695#9313140:

I don't get why. We have

'wikisource' => '.wikisource.org',
'sourceswiki' => '.wikisource.org',

in the $wmgCentralAuthCookieDomain config. At least in a debug shell, it works as expected.

I guess we can add wikisources to rOMWCdf0dafd48dce: CentralAuth: Clear domain cookie when setting non-domain cookie and that will either make it better or make it worse.

Yeah, the current configuration looks correct to me.

The domain-less cookies are from before rOMWCbeb76abd7344: Generalize Meta/Commons exceptions for CentralAuth cookie handling. We didn't notice this when making that change, but taking a closer look now, I can see that the old code with regexps for the domains was not setting the domain for sourceswiki, because (unlike every other Wikimedia wiki!) its domain has only two segments – it's just "wikisource.org" and not "www.wikisource.org" – and the regexp did not match it.

This explains why the new cookies for wikisource.org conflict with the old cookies for wikisource.org, like in T350695#9313416, but opposite (old cookies did not have the 'domain' parameter, new ones do).

But this makes me wonder. Even before that config change, the language-specific Wikisources at xx.wikisource.org have been setting cookies with 'domain' set to '.wikisource.org'. Why were they not conflicting with the cookies without 'domain' set by the multilingual Wikisource at wikisource.org?

And I think the answer is that they actually were conflicting, and the configuration for wikisource.org has just been broken for years. I found several bug reports that complain specifically about wikisource.org: T127650, T145545, T263888. However, the problem would go away after they visited xx.wikisource.org, so it was never investigated properly. We fixed it by accident, unfortunately causing this issue instead.

In T351685#9356966, @Soda wrote:

The gadget is loading code from wikisource.org which is causing the session cookie conflicts mentioned, this should be temporary untill the patch that Tgr has proposed has been merged and deployed

There are at least three other gadgets on enWS that crossload code from mulWS. They're not default, but since this affects users with an account the effect should be the same for those with these enabled. frWS crossloads at least two gadgets and loads code from mulWS in its Common.js (as default as you can get). plWS loads from mulWS in at least one gadget and thrice in Common.js. Smaller projects often load all their gadgets that way (but I haven't checked specifically because they tend to look like this).

IOW, there's nothing really unique about MediaWiki:InterWikiTransclusion.js on enWS in that sense.

The only obvious thing I can think of is that MediaWiki:InterWikiTransclusion.js actually calls a remote API and asks it to render wikitext, whereas the other gadgets operate locally once the code is loaded.

In T351685#9357218, @Xover wrote:

In T351685#9356966, @Soda wrote:

The gadget is loading code from wikisource.org which is causing the session cookie conflicts mentioned, this should be temporary untill the patch that Tgr has proposed has been merged and deployed

There are at least three other gadgets on enWS that crossload code from mulWS. They're not default, but since this affects users with an account the effect should be the same for those with these enabled. frWS crossloads at least two gadgets and loads code from mulWS in its Common.js (as default as you can get). plWS loads from mulWS in at least one gadget and thrice in Common.js. Smaller projects often load all their gadgets that way (but I haven't checked specifically because they tend to look like this).

IOW, there's nothing really unique about MediaWiki:InterWikiTransclusion.js on enWS in that sense.

The only obvious thing I can think of is that MediaWiki:InterWikiTransclusion.js actually calls a remote API and asks it to render wikitext, whereas the other gadgets operate locally once the code is loaded.

Those three other gadgets probably also affect users who have them enabled. The problem here is not with the gadget itself, but the fact that it is enabled by default.

In T351685#9357214, @matmarex wrote:

... because (unlike every other Wikimedia wiki!) its domain has only two segments – it's just "wikisource.org" and not "www.wikisource.org" – and the regexp did not match it.

Oh right, the regex has a dot at the end, I didn't notice that.

And I think the answer is that they actually were conflicting, and the configuration for wikisource.org has just been broken for years. I found several bug reports that complain specifically about wikisource.org: T127650, T145545, T263888. However, the problem would go away after they visited xx.wikisource.org, so it was never investigated properly.

Yeah I think this was just broken, and not noticed because not many people use both old Wikisource and a language-specific one. T124620 was probably also the same issue and we misidentified it (we fixed a bug in CA but it wasn't really the root cause).

To the degree it is 1) technically feasible and 2) will actually help, I don't think a proposal to rename "wikisource.org" to something with a third segment will be received as an attack on the very foundations of… etc. We tend to call it "Multilingual Wikisource" or mulWS nowadays, and the two-segment name was a call made way back in the mists of time when the alternative was more "oldwikisource" than anything else. I can't predict how the communities will land on the question (they may prefer to maintain the status quo), but asking is at least an option.

Last I heard, renaming a wiki was infeasible in practice; but if that's changed and mulWS is the only oddball and it's causing issues like this one periodically…

In T351685#9357570, @Xover wrote:

Last I heard, renaming a wiki was infeasible in practice

Not infeasible but a lot of work, while fixing this bug directly isn't hard.

but if that's changed and mulWS is the only oddball and it's causing issues like this one periodically…

It's definitely an outlier and it would be nice not to have to think about it. Not sure if it's worth the effort for a rename, though. Anyway, the relevant task is T64717: Move oldwikisource on www.wikisource.org to mul.wikisource.org.

(We could also maybe just flip the www.wikisource.org -> wikisource.org redirect. All of our other multilingual wikis on a second-level domain, like mediawiki.org or wikidata.org, behave that way. Granted wikisource is the only wiki which has both a generic version and a language family, so maybe there is some special reason I'm missing that applies to it.)

Scheduled for deployment today: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20231127T2100

Change 976864 merged by jenkins-bot:

[operations/mediawiki-config@master] CentralAuth: Fix wikisource.org cookie handling

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

Mentioned in SAL (#wikimedia-operations) [2023-11-27T21:04:27Z] <cjming@deploy2002> Started scap: Backport for [[gerrit:976864|CentralAuth: Fix wikisource.org cookie handling (T351685)]]

Mentioned in SAL (#wikimedia-operations) [2023-11-27T21:05:43Z] <cjming@deploy2002> cjming and tgr: Backport for [[gerrit:976864|CentralAuth: Fix wikisource.org cookie handling (T351685)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2023-11-27T21:15:54Z] <cjming@deploy2002> Finished scap: Backport for [[gerrit:976864|CentralAuth: Fix wikisource.org cookie handling (T351685)]] (duration: 11m 26s)

Yep, fixed!