On Wed, Nov 5, 2008 at 12:28 PM, Petr Kadlec <petr.kadlec(a)gmail.com> wrote: That still seems like a bug on our part. The extra (and unintuitive) step shouldn't be necessary.

Just to add my $0.02: I agree that this is due to something beyond the control of mediawiki and probably shouldn't be worked around - Clearing the box down with JS should be easy but if you're going to wait more than a few milliseconds to do it, an experienced user may well have started to type into the box by that time - and silently chopping off the first few chars of your old password is not a great plan. (This is more likely to happen if it's driven by the page's onload event which won't fire until after all images etc... Are loaded meaning the PW box itself may have been visible for a number of seconds on a slow connection) I was under the impression that FF and other browsers remembered passwords based on the URL and field names (please correct me if I'm wrong) so I'm not sure why it's pre-populating the password on that page (the edit box has a different name to the login page) unless someone has specifically prompted the browser to remember their password on the change password (preferences) page - which seems to me to be utterly pointless in the first place. Can you clarify why exactly FF is remembering the password on that page - did you ask it to? -----Original Message----- From: wikitech-l-bounces(a)lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Petr Kadlec Sent: 05 November 2008 17:42 To: Wikimedia developers Subject: Re: [Wikitech-l] Bug in user prefereces 2008/11/5 Aryeh Gregor <Simetrical+wikilist(a)gmail.com>om>: wrote: leading And what do you think we should do? From our viewpoint, the situation is identical to the user trying to set his password to empty string. So, if a user really does try to do that, should we just ignore it, not telling him anything? Hmmm... We could say "if you tried to clear your password, we ignored it, as that is not allowed, but other preferences have been changed successfully, but I am not sure how much of an improvement is that. We might also try to outsmart Firefox by clearing the editbox explicitly using JavaScript shortly after the page is loaded. (I don't know if that would even work, but maybe worth an attempt.) -- [[cs:User:Mormegil | Petr Kadlec]] _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ________________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ P Please think of the environment before you print this email ________________________________________________________________________ This email and any files transmitted with it are private and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please return it to the address it came from telling them it is not for you and then delete it from your system. This footnote also confirms that this email message has been swept for the presence of computer viruses but this in no way indicates that the message is virus free. Teleperformance is a trading style of MM Teleperformance Ltd: Reg No. 02060289 England: Registered Office: St James House, Moon Street, Bristol, BS2 8QY. VAT No.763 0980 18 _______________________________________________________________________

MinuteElectron wrote: I admit I hadn't considered that, however, the login page uses <input name="wpPassword"> whereas the preferences page uses <input name="wpOldpass"> (at least on my install) so I'm surprised it's confusing the two unless it's been specifically told to remember the old password when a password was changed - in fact it would be interesting to know if it's populating the correct "old" password or is in fact using a very old one. P Please think of the environment before you print this email ________________________________________________________________________ This email and any files transmitted with it are private and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please return it to the address it came from telling them it is not for you and then delete it from your system. This footnote also confirms that this email message has been swept for the presence of computer viruses but this in no way indicates that the message is virus free. Teleperformance is a trading style of MM Teleperformance Ltd: Reg No. 02060289 England: Registered Office: St James House, Moon Street, Bristol, BS2 8QY. VAT No.763 0980 18 _______________________________________________________________________

Dear All, I am new to developing extensions for mediawiki and need your guidance with a particular extension I am working on for my research. Basically, I want to color the words in an article based on its age. As a first step, I am writing a simple extension which just colors all words in an article. I am having problems with the hook I need to use. I use the 'OutputPageBeforeHTML' hook to add span tags to the text before it is actually displayed. But that does not seem to be working. So I have 2 questions. 1. Which hook would be the right one to add span tags to every word in an article. 2. How do i extract the words in an article, without the markup details? Any help would be appreciated. Thanks Avanidhar

On Wed, Nov 5, 2008 at 12:41 PM, Petr Kadlec &lt;petr.kadlec(a)gmail.com&gt; wrote: That seems fairly reasonable, to be honest. Fields that aren't filled in can be ignored. Isn't there some HTML directive for inputs saying "don't auto-fill this box"?

On Wed, Nov 5, 2008 at 7:40 PM, Brad Jorsch &lt;b-jorsch(a)northwestern.edu&gt; wrote: Here is a ridiculous hack to able that: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!ATTLIST html xmlns:goo CDATA #FIXED "http://zerror.com/google/autocomplete" <!ATTLIST input autocomplete CDATA #IMPLIED] <html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml" xmlns:goo="http://zerror.com/google/autocomplete" <head><title>Example</title></head <body <input type="text" name="search" autocomplete="on" value="Looks mon, no hands!" / </body</html -- -- ℱin del ℳensaje.

2008/11/8 Timwi &lt;timwi(a)gmx.net&gt;et>: Some wikis allow users to have no password (and it's still the default setting), and in that case, it is a completely valid operation (see http://www.mediawiki.org/wiki/Manual:$wgMinimalPasswordLength). -- [[cs:User:Mormegil | Petr Kadlec]]

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Petr Kadlec wrote: We're still kind of assuming it's something like this problem. :) The proper thing to do is to move the password reset form out of preferences to its own form -- it really shouldn't be there anyway. - -- brion

Hoi, I do not have the illusion that my need for preferences that have a global impact is unique. When I read the bug, I find that it was looked at for the last time in 2004. In the mean time we have implemented SUL, in the mean time much of what has been said in the bug report there is not that relevant anymore. The problem that Timwi described is one that needs a solution. When people aim to fix this, it makes sense to do a proper job and consider the other issues that exist as well. Because of this I think my reaction to this thread is appropriate. :) It would be nice not to do the job, but to do a great job. Thanks, GerardM On Thu, Nov 6, 2008 at 2:38 PM, Petr Kadlec &lt;petr.kadlec(a)gmail.com&gt; wrote:

Hoi, If we are to have global preferences fine. With the defaults for "preferred math display" or "image size" I have no problem. The offset for time is not usuable and i have user profiles effectively in two time zones; this is confusing So I agree, create a framework that allows for global preferences and implement the time offset / time zone soonest. Thanks, GerardM On Thu, Nov 6, 2008 at 3:57 PM, Platonides &lt;Platonides(a)gmail.com&gt; wrote:

I thought it didn't have anything to do with the preferences system itself, but was a performance issue; the context switching needed to get the preferences everytime would be too darn expensive. I vaguely recall Domas mentioning something like that... Siebrand -----Oorspronkelijk bericht----- Van: wikitech-l-bounces(a)lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Namens Alex Verzonden: donderdag 6 november 2008 20:49 Aan: Wikimedia developers Onderwerp: Re: [Wikitech-l] Bug in user prefereces I don't think there's anyone who thinks that global preferences would be a bad idea (or if there are, they're a tiny minority). It just hasn't been done yet. Any global preferences system would probably come after a rewrite of the current preferences system[1] as it would probably be done in mostly the same way. Doing it one preference at a time would be rather inefficient. The main issue is that you may not want the same preferences everywhere. For example, email notification settings, which also has the issue of not being consistent across projects. I may want notification for watchlisted changes on small projects I don't check often, but not for commons and meta, as I check those often. Or you may not want to use UTC on projects that use a different default timezone for signatures and such. So the global preferences would have to be locally overridable. [1]<http://www.mediawiki.org/wiki/Deficits_of_the_current_preferences_sys… -- Alex (wikipedia:en:User:Mr.Z-man)

On Fri, Nov 7, 2008 at 11:18 AM, Aryeh Gregor &lt;Simetrical+wikilist(a)gmail.com&gt; wrote: We already cache global user objects in memcached, and memcached hits are cheap, anyway (on the order of a few hundred us). -- Andrew Garrett