It would seem that the bugzilla https://bugzilla.wikimedia.org/show_bug.cgi?id=23710 would fall under that category, and to note that it is still marked as new. Can it be tied to this process? Regards, Andrew Quoting Brion Vibber <brion(a)pobox.com>om>: ---------------------------------------------------------------- This message was sent using iSage/AuNix webmail http://www.isage.net.au/

Brion Vibber wrote: The original spec had feedback based precisely on enwiki numbers. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-August/022220.html So about 100? Note that there are invalid addresses marked as confirmed in wikipedia.

Brion Vibber (2011-01-25 02:51): Could you check for validated address containing commas in user names part? The RegExp from mediawiki.util.js did/does allow them. Regards, Nux.

On Mon, Jan 24, 2011 at 8:51 PM, Brion Vibber &lt;brion(a)pobox.com&gt; wrote: But note that I counted only the worsening of false negatives, not the improvement in false positives -- I only looked at confirmed addresses. It seems likely that a vastly larger number of undeliverable addresses would be rejected at an early stage with the more restrictive check, allowing users to correct them before submitting so that the e-mail doesn't get lost in the ether. So it seems like a clear improvement overall. However, the code should probably at least strip whitespace (including internal whitespace, not just trailing/leading) onkeypress/oninput/onsubmit or such. This came up in something like 0.1% of the sample. Non-techy users would probably get pretty confused by a trailing space messing the whole thing up. I suggest that for Firefox 4, we shortcut the JavaScript logic and just use type=email. It's pretty nicely designed. Here's a test case (this is a URL, just paste all the lines in Firefox 4's URL bar): data:text/html,<form><input type=email name=email placeholder=E-mail> <br><input placeholder="Some other input"><br><input type=submit></form> Firefox 4b9 seems not to implement the latest spec update, so foo@localhost doesn't work, but that should be an easy fix. If someone is willing to poke at their source code, I imagine it'd be possible to get the updated check in the final release. Unfortunately, WebKit's form constraint validation implementation is broken all over the place, and Opera's is pretty ugly (like only checking validity onsubmit), so we should probably blacklist them if we use any form validation features.

* Aryeh Gregor &lt;Simetrical+wikilist(a)gmail.com&gt; [Wed, 26 Jan 2011 15:09:17 -0500]: Surely it should. In a very similar manner, I've had a trouble with local MediaWiki installation (old 1.14, haven't checked with newer ones), when I've created user accounts and sent these via the email, people were unable to login, because when you select a text line using a mouse, Thunderbird mail sometimes copies line feed character into clipboard, so it was pasted into the password field then and the password didn't match. Users were frustrated. I've explained them that line feed is being placed into the clipboard which is visible when you paste it into the text editor. I am unsure which browser they have been used, maybe some browsers strip 13 / 10 from text inputs, maybe don't. Dmitriy

* Aryeh Gregor &lt;Simetrical+wikilist(a)gmail.com&gt; [Thu, 27 Jan 2011 14:27:21 -0500]: http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-t… Oops.. My mistake - it seems that Thunderbird mail appends extra space character (32) to the end of selection in the clipboard instead (when the password is located in separated text line and one selects the complete line using mouse), not CR / LF. However, as the password field input value is hidden, users cannot realize why he / she cannot login when copying / pasting the password from TB mail. It would be more user-friendly in case trim() was used. Dmitriy