This about:config workaround is not happening for me. Is this still a problem for others? It's driving me up the wall.

I can verfiy that the workaround is working on FF 50.1.0 / Ubuntu. (Steps to reproduce: log in on enwiki, then start opening links to other wikis' main pages from the language panel on the left. After opening about the third of them, you won't be logged in anymore.)

Works for me. I did set a BIG number, 5000 from memory, as I do have lots of cookies from 800 wikis. @Koavf, did you set type as INTEGER??? If not, it will fail.

@Billinghurst I can only make it a String value. It won't let me create it as an Integer (or Boolean, which of course I don't want). Edit: Deleted the entry and tried again. I'll complain here if it doesn't work. Thanks, guys.

@Koavf

Copy the name to your clipboard

Delete the parameter. Close and reopen your browser and (re)create it. When creating, right click > New > (choose) integer and then add your detail again. [PS. Don't feel bad, my first go wasn't correct, and why I amended the details up top.

Your problem is that string cannot count to your value so you have the default.

Happening to me in bnwp again.

@Bodhisattwa: Please see previous comments. If you have a specific question, please ask your specific question, as "me too" comments do not help anyone, sorry. :)

Pinging Analytics as this probably means that the various cookie-based stats we have are unreliable for Firefox.

If we have to live with this in the long term (looks like upstream haven't quite made up their minds yet), we can probably push most cookies to the second-level domain. For analytics-oriented cookies there is no reason not to, and for user preferences, consistent cross-wiki behavior would almost be a good thing - except that it will only be consistent within different language editions of the same project. That's pretty confusing but not impossible to live with. (OTOH most user preferences should work fine in localStorage, we would only have to fix T121646: Document usage policy for LocalStorage in MediaWiki code so that we can handle expiry.)

Thanks for the ping, but the only cookie-based stats take session loss into account. We'll keep in mind for future work, untagging for now.

The problem appeared today again (message). Only after removing all the cookies I could save a page again.

The problem consists also out of:

• almost endless amount of cookies for Wikimedia sites, while I login only in one place!
• storage of too many settings in the cookies, including the annoying message which editor I want to use while I am already editing!
• all clicked away banners appear again!

There is just one conclusion: this cookie system is broken.

There is a maximum of 30 days that I could stay logged in, but I do not even reach those 30 days if I have this error every week.

Please fix this broken system!

• Keep preferences in the preferences and not elsewhere
• If a message is shown and the user can choose something (like which editor to use), save this in the preferences and never ever in cookies!

Thank you!

The Firefox bug https://bugzilla.mozilla.org/show_bug.cgi?id=1319403 has apparently been fixed and it currently planned to be released in Firefox 54.

Thank Goodness.

In T151770#3053144, @Romaine wrote:

There is a maximum of 30 days that I could stay logged in, but I do not even reach those 30 days if I have this error every week.

One small note, the old "30 days" limit was increased to 365 days, a few months ago. (T68699) :-)

For us highly-active cross-wiki Firefox users, the best solution is: (A) to do the fix described in the task description, and (B) wait for Firefox54 to fix it properly (it's launching as the official version in June, according to https://en.wikipedia.org/wiki/Firefox_version_history#Firefox_54 ). (The other ideas sound good to me, but aren't likely to change before June!)

In the meantime, maybe we should include a note (link to a page that explains it in simple terms?) this in the error message? It's bound to be a very common cause for this problem, and it could be helpful for users to know how to solve it.

In T151770#3059447, @matmarex wrote:

The Firefox bug https://bugzilla.mozilla.org/show_bug.cgi?id=1319403 has apparently been fixed and it currently planned to be released in Firefox 54.

Where by "fixed" they mean that they will now delete cookies randomly instead of starting with session cookies :-/

In T151770#3059513, @Johan wrote:

In the meantime, maybe we should include a note (link to a page that explains it in simple terms?) this in the error message? It's bound to be a very common cause for this problem, and it could be helpful for users to know how to solve it.

Good idea. I've put a simple version at https://www.mediawiki.org/wiki/Firefox_users_and_session_loss_bug
If a dev agrees, then please update the string Mediawiki:Session fail preview (wherever that is stored) to include a link to that mediawikiwiki page, using the text "Firefox users, please see this page." (linking the whole sentence). Or similar.

In T151770#3059822, @Tgr wrote:

In T151770#3059447, @matmarex wrote:

The Firefox bug https://bugzilla.mozilla.org/show_bug.cgi?id=1319403 has apparently been fixed and it currently planned to be released in Firefox 54.

Where by "fixed" they mean that they will now delete cookies randomly instead of starting with session cookies :-/

There doesn't seem to be much random about it, it looks like they're going with basically a straight LRU now with the only potential randomness being in choosing the specific cookie if there's a tie for LRU.

Hi all, @Kusurija fixed the problem temporary by increasing network.cookie.maxPerHost to 4000 (if 5 cookies per project it should be enough even all 750+ projects were counted together and he was editing all of them) but it appeared again. I adviced him to increase the value to 10000 (to be sure it isn't the same problem) but it didn't help. Symptoms are the same as this problem so I'm not creating new ticket. Can somebody tell me how can he fix it?

@Urbanecm the (default) maximum number of cookies is 3000, so you have to increase that too through the network.cookie.maxNumberpreference.

@P.a.a Thank you!

BTW would it be fixed on our side anytime? Or is this just monitoring task?

In T151770#3136297, @Urbanecm wrote:

Hi all, @Kusurija fixed the problem temporary by increasing network.cookie.maxPerHost to 4000 (if 5 cookies per project it should be enough even all 750+ projects were counted together and he was editing all of them) but it appeared again. I adviced him to increase the value to 10000 (to be sure it isn't the same problem) but it didn't help. Symptoms are the same as this problem so I'm not creating new ticket. Can somebody tell me how can he fix it?

I have 5000 working fine, and there wouldn't be that many users who do more xwiki work than myself. (10s to 100s of people max). Do ensure that they have type set as integer, otherwise it won't be counting.

In T151770#3136374, @Urbanecm wrote:

BTW would it be fixed on our side anytime? Or is this just monitoring task?

@Quiddity, this is a good question. Are we managing what has become a little of cookie bloat? Or at least are the prime designers at least thinking about this issue? Can some of the wiki specific cookies be domain specific? Even if one became x-domain that would reduce the numbers.

In T151770#3136432, @Billinghurst wrote:

In T151770#3136374, @Urbanecm wrote:

BTW would it be fixed on our side anytime? Or is this just monitoring task?

@Quiddity, this is a good question. Are we managing what has become a little of cookie bloat? Or at least are the prime designers at least thinking about this issue? Can some of the wiki specific cookies be domain specific? Even if one became x-domain that would reduce the numbers.

See T110353. Krinkle has significantly reduced the number of cookies by moving saved values from cookies to localStorage and sessionStorage, as well as fixing blatant mistakes like https://meta.wikimedia.org/w/index.php?diff=16372260.

When I checked the number of cookies I had on March 9 on svwiki, it was 14. Today it's 10. And that number will only continue to drop because there are changes that have been merged that switches from using cookies to (local|session)Storage. In about a month, I expect to see no more than 6 cookies (CP, VEE, WMF-Last-Access, xxwikiSession, xxwikiUserID and xxwikiUserName), assuming that no temporary things like fundraising banners or steward vote eligible stuff pops up.

In T151770#3136429, @Billinghurst wrote:

I have 5000 working fine, and there wouldn't be that many users who do more xwiki work than myself. (10s to 100s of people max). Do ensure that they have type set as integer, otherwise it won't be counting.

I adviced adding the variable to config previously and it helped, so probably it is an integer but I'll ask him.

In T151770#3136429, @Billinghurst wrote:

In T151770#3136297, @Urbanecm wrote:

Hi all, @Kusurija fixed the problem temporary by increasing network.cookie.maxPerHost to 4000 (if 5 cookies per project it should be enough even all 750+ projects were counted together and he was editing all of them) but it appeared again. I adviced him to increase the value to 10000 (to be sure it isn't the same problem) but it didn't help. Symptoms are the same as this problem so I'm not creating new ticket. Can somebody tell me how can he fix it?

I have 5000 working fine, and there wouldn't be that many users who do more xwiki work than myself. (10s to 100s of people max). Do ensure that they have type set as integer, otherwise it won't be counting.

It really is an integer. There was 4000 previously and it was working but it suddently stopped working with no reason and started giving the same kind of error. Any solution came to my mind didn't help. This problem is in some way different. It affect only Wikipedia not other families.

In T151770#3136328, @P.a.a wrote:

@Urbanecm the (default) maximum number of cookies is 3000, so you have to increase that too through the network.cookie.maxNumberpreference.

network.cookie.maxNumber was increased too but it do not work.

I'm receiving some emails from @Kusurija, this problem stops him with his work and can't do anything but wait for fixing the problem.

BTW why we don't have just one cookie with random (or permanent) user id which is sent after all requests at all WMF's projects, everything else can and should be stored serverside and anonymous shouldn't be allowed to set anything permanently (only valid to the end of current session) and politely asked to create an account.

brute force check: suggest going in an deleting a swathe of wikipedia cookies and see whether that removes the problem. Or consider one of the add-ons that allows counts and the like to get you a better idea of what is the issue.

I'll ask him.

Just thinking loudly: Interesting is that it usually doesn't work but sometimes the system allows him to save an edit, https://cs.wikipedia.org/w/index.php?title=Diskuse_s_wikipedistou:Kusurija&diff=14865891&oldid=14865643 for example.

In T151770#3147927, @Billinghurst wrote:

brute force check: suggest going in an deleting a swathe of wikipedia cookies and see whether that removes the problem. Or consider one of the add-ons that allows counts and the like to get you a better idea of what is the issue.

He was deleting cookie after cookie and it did not fixed the problem. However, sometimes the server allows to save an edit without any deleting. The server of course was sending deleted cookies again and again. Here is the list of cookies he tried to delete.

I don't know if you but I really have no idea where is the problem and if it is really the same problem (even I think so).

Affected cookies

All of following cookies were deleted multiple times but it didn't fixed the problem.

• WMF-Last-Acces
• cpPosTime
• cswikiUserID
• cswikiUserName
• cswikiSession
• CP
• UseDC
• UseCDNCache

Ping. This is high priority and nothing is happening.

I still feel people should complain to Mozilla about this; the MediaWiki behavior is reasonable.

In T151770#3419197, @Tgr wrote:

I still feel people should complain to Mozilla about this; the MediaWiki behavior is reasonable.

I'm not affected. I just made a fast look at tickets in User-Urbanecm and saw that this is without update and high priority.

In T151770#3059924, @Quiddity wrote:

In T151770#3059513, @Johan wrote:

In the meantime, maybe we should include a note (link to a page that explains it in simple terms?) this in the error message? It's bound to be a very common cause for this problem, and it could be helpful for users to know how to solve it.

I've put a simple version at https://www.mediawiki.org/wiki/Firefox_users_and_session_loss_bug
If a dev agrees, then please update the string Mediawiki:Session fail preview (wherever that is stored) to include a link to that mediawikiwiki page, using the text "Firefox users, please see this page." (linking the whole sentence). Or similar.

Could a developer provide feedback on this proposal (and clarify where that's stored)?

It's stored in languages/i18n/en.json, like most core i18n messages. But note that editing it there won't affect wikis that override the message locally, like enwiki does.

Made the change on enwp as it seems helpful to our editors who are affected by this

In T151770#3500908, @Samtar wrote:

Made the change on enwp as it seems helpful to our editors who are affected by this

Should the page it links to be protected?

Has there been vandalism? If not, why do you ask?

In T151770#3505197, @Aklapper wrote:

Has there been vandalism? If not, why do you ask?

Maybe because pages linked from system messages are usually semiprotected to prevent vandalism?

In T151770#3505049, @TerraCodes wrote:

In T151770#3500908, @Samtar wrote:

Made the change on enwp as it seems helpful to our editors who are affected by this

Should the page it links to be protected?

I think semiprotection will be more than useful.

This is outside Phabricator scope. If you think the page should be (un)protected https://en.wikipedia.org/wiki/Wikipedia:Requests_for_page_protection is the page you're looking for ;-)

In T151770#3505583, @Urbanecm wrote:

In T151770#3505197, @Aklapper wrote:

Has there been vandalism? If not, why do you ask?

Maybe because pages linked from system messages are usually semiprotected to prevent vandalism?

In T151770#3505049, @TerraCodes wrote:

In T151770#3500908, @Samtar wrote:

Made the change on enwp as it seems helpful to our editors who are affected by this

Should the page it links to be protected?

I think semiprotection will be more than useful.

Yep, plus anyone could edit the page and change it so that does something malicious instead.

In T151770#3505585, @MarcoAurelio wrote:

This is outside Phabricator scope. If you think the page should be (un)protected https://en.wikipedia.org/wiki/Wikipedia:Requests_for_page_protection is the page you're looking for ;-)

The page is on mediawiki, not enwiki.

https://www.mediawiki.org/wiki/Project:Requests

Page now semi-protected.

Since Firefox 54 was released a while back, can we close this ticket?

I am fine with closing it. I did not had any issues with it for a while.

With Chromium 60 I experience a similar problem by the way: according to http://browsercookielimits.squawky.net/ only some 180 cookies in total are allowed, so if you just open a handful tabs and maybe dismiss some sitenotices and centralnotices plus half a dozen VisualEditor splashscreens per wiki then your session is already erased.