Page MenuHomePhabricator

Frequent loss of session data in Firefox (since around 2016-11-28)
Closed, ResolvedPublic

Assigned To
Authored By
Jarekt
Nov 28 2016, 4:50 PM
Referenced Files
F5301629: T151770b.png
Jan 17 2017, 8:09 PM
F5301630: T151770c.png
Jan 17 2017, 8:09 PM
F5301628: T151770a.png
Jan 17 2017, 8:09 PM
F5301631: T151770d.png
Jan 17 2017, 8:09 PM
F5194468: Archive 16-12-30 20-41-45
Dec 30 2016, 6:59 PM
F5111237: Archive 16-12-20 18-31-50.7z
Dec 20 2016, 5:35 PM
F5111234: Archive 16-12-20 18-24-44.7z
Dec 20 2016, 5:35 PM
F5061937: Archive 16-12-15 18-31-37.7z
Dec 15 2016, 5:36 PM
Tokens
"Like" token, awarded by Liuxinyu970226.

Description

Lately I often get error "Sorry! We could not process your edit due to a loss of session data. Please try saving your changes again. If it still does not work, try logging out and logging back in. " while saving edits on EN-WIKI. In the past on a rare occasion when I got this error I could just press save again and it would work. This time multiple saves do not help nor relogging. I suddenly can not edit at all on any pages. I did some experiments trying to understand the issue, and it seems like I can use tools that edit the page in my name. The only workaround I found was to switch browsers. I usually edit in Firefox and I switch to Chrome.

New Picture.png (1×1 px, 136 KB)


This is Firefox bug #1319403 (cookie limits seem to be applied to the second-level domain). Workaround: set network.cookie.maxPerHost as an integer much higher in Firefox's about:config menu.

Specifically:

  1. Open a new tab or window
  2. type or paste about:config and click [Enter]. (There might be a warning screen after this)
  3. right click anywhere in the table of results
  4. select New
  5. select Integer
  6. type or paste network.cookie.maxPerHost as the preference name, and click [ok]
  7. type a value (see below), and click [ok]
  8. Done!
    • (You might need to reload the page, or re-log-in, or restart your browser, for the fix to start working. But probably not.)

Value: any number between 200 and 2000 should work fine. Estimate 5+ cookies per wiki, and only count the project (e.g. Wiktionary) that you access the most languages of.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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.

@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.)

Aklapper updated the task description. (Show Details)

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.

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.

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 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.

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.

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

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.

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.

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.

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.

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.

@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.

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.

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.

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.

Aklapper lowered the priority of this task from High to Medium.Jul 10 2017, 8:29 AM

Lowering priority as the preferred "solution" is out of Wikimedia's hands.

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

Mattflaschen-WMF renamed this task from Frequent loss of session data (since around 2016-11-28) to Frequent loss of session data in Firefox (since around 2016-11-28).Aug 4 2017, 7:28 PM
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?

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#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 ;-)

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#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.

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.

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.

Jarekt claimed this task.

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.