Wikimedia Bugzilla is closed!

Sounds like bug 47694

(In reply to comment #0)
> If a user checks the 'Keep me logged in' box when logging in, it only does so
> for a finite amount of time, about a month by default. The label does not
> reflect this - by not specifying any time period, the expectation is that the
> login will last indefinitely, which is simply not the case and has already
> led
> to some confusion amongst users.
> 
> While the English Wikipedia modified their own interface message to specify
> the
> time period, that clarification should be added to core.

This bug is functionally the same as bug 47694. For all the reasons outlined there, adding exact time expiry statements is not a common practice in login UI and we don't need it. 

For MediaWiki core, the current default of wgCookieExpiration is apparently 180 days, or nearly six months.  Wikimedia sites currently do this with a 30 day expiry, but frankly it's a broken user experience and we will be getting rid of it soon with the new privacy policy coming in to place.

Since it's the exception, not the norm, to have a shorter expiry time for users who opt in to being remembered, this logic would mostly just be unnecessary cruft. Telling a user they are going to be remembered for exactly 180 days is bizarre and unnecessary detail. All the user wants to know is if they are or are not going to have to log in every time they open their browser and visit the wiki.

Please stop closing bugs as wontfix when the consensus is clearly against you.

Common is not the same thing as good, the default expiry also defies expectation because it's expiring, and we normally do try to support edge cases. If a user wants to know if they're going to have to log in again the next time, we should not be labelling the checkbox in a way that may not answer the question accurately. I hope this helps clarify things.

(In reply to comment #3)
> Please stop closing bugs as wontfix when the consensus is clearly against
> you.
> 
> Common is not the same thing as good, the default expiry also defies
> expectation because it's expiring, and we normally do try to support edge
> cases. If a user wants to know if they're going to have to log in again the
> next time, we should not be labelling the checkbox in a way that may not
> answer
> the question accurately. I hope this helps clarify things.

Bugs don't operate on majority rule. We specifically removed the time expiry during the login redesign for many of the reasons I outlined. We're not going to put it back. 

Building interface defaults to support edge cases is terrible terrible practice. It's part of the reason we have so much configuration and preference bloat in MediaWiki.

(In reply to comment #4)
> Bugs don't operate on majority rule. We specifically removed the time expiry
> during the login redesign for many of the reasons I outlined. We're not going
> to put it back.
Who's we and how do they have this kind of authority to suppress discussion on a perfectly valid and sane enhancement request?

> Building interface defaults to support edge cases is terrible terrible
> practice. It's part of the reason we have so much configuration and
> preference
> bloat in MediaWiki.
This might be true for some websites, such as the WMF's, but there are third parties out there who don't stick to the default configuration. Having cookies expire too quickly is annoying -- especially so when your definition of "too quickly" is way different than the site's operator's -- but it's a tad bit less annoying when you know that "your login expires in 2 days" instead of "your login expires in 180 days".

This is a valid enhancement request and very easy to do, so we obviously should do so in core, to provide /sane defaults/. Sure, we can call the "user name" box on Special:UserLogin "name" -- less verbose, and, by your definition, less "cruft", but also way more confusing. Name, but whose? My real name? The name I chose during the signup process? My friend's dog's name?

So yes, let's do this instead of bikeshedding over it. You can have it customized/overridden for WMF sites just as you like, I won't comment on that, but the software defaults should stay sensible.

To clarify: the expiry time should not be displayed if it's set to indefinite. This may also apply if it's set to a sufficiently long duration (for instance if it expires after 6 months days, that may well be plenty that it doesn't really matter anymore), though what the boundary would be, or if this is indeed that case, is more up in the air. 

It is most important to specify the duration where it is shorter, such as of a week, 30 days, etc. There, the logins will be expiring quite frequently, and for the users, quite unexpectedly: if they told it to keep them logged in, it will appear to them that they are being logged out after they specifically told it to not log them out, because that's what it said.
The checkbox needs to be labelled correctly, because otherwise it defies user expectation, and could even lead them to assume the checkbox does nothing at all.

(Of course if you can convince them it does nothing, you can then use that as a rationale for removing it entirely, but at least I don't think anyone's trying to go that route here.)

(In reply to comment #5)
> This might be true for some websites, such as the WMF's, but there are third
> parties out there who don't stick to the default configuration. Having
> cookies
> expire too quickly is annoying -- especially so when your definition of "too
> quickly" is way different than the site's operator's -- but it's a tad bit
> less
> annoying when you know that "your login expires in 2 days" instead of "your
> login expires in 180 days".
> 
> This is a valid enhancement request and very easy to do, so we obviously
> should
> do so in core, to provide /sane defaults/. Sure, we can call the "user name"
> box on Special:UserLogin "name" -- less verbose, and, by your definition,
> less
> "cruft", but also way more confusing. Name, but whose? My real name? The
> name I
> chose during the signup process? My friend's dog's name?

I have seen no evidence that any number of MediaWiki installs would set cookie expiry to two days. That would defeat the purpose of providing an option to remember a user's login session.

> 
> So yes, let's do this instead of bikeshedding over it. You can have it
> customized/overridden for WMF sites just as you like, I won't comment on
> that,
> but the software defaults should stay sensible.

I'm not closing the bug just for formality's sake. I'm closing it because we should not dump more unnecessary nonsense back in to the login form. You're going to get the same response on patches.

I was going to say that I agree with the WONTFIX, then I read this:

(In reply to comment #6)
> To clarify: the expiry time should not be displayed if it's set to
> indefinite. This may also apply if it's set to a sufficiently long
> duration (for instance if it expires after 6 months days, that may
> well be plenty that it doesn't really matter anymore), though what
> the boundary would be, or if this is indeed that case, is more up in
> the air.

And it seems more sensible than just WONTFIXing.


(In reply to comment #7)
> I have seen no evidence that any number of MediaWiki installs would
> set cookie expiry to two days. That would defeat the purpose of
> providing an option to remember a user's login session.

My bank logs me out after 10 minutes. Two days might be reasonable in
some edge cases (but I have no examples ready).

Okay, I misread the first comment of Bug 47694. This is a duplicate. This all should have been there after all.

*** This bug has been marked as a duplicate of bug 47694 ***

*** Bug 70348 has been marked as a duplicate of this bug. ***