dionyziz wrote:

Userlogin.php

attachment Userlogin.php ignored as obsolete

avarab wrote:

This sounds very good, but could you please supply a patch to the current CVS
HEAD version rather than a complete replacement for the file, it might even get
in 1.5 then;)

avarab wrote:

Userlogin.php patch

Attached:

avarab wrote:

I made a patch myself and attached it, howver I'm unable to get it to work in my
browser (firefox 1.0), what browsers did you test it with?

dionyziz wrote:

Thanks for creating a patch file! I didn't know how to make one... Regarding the
testing, I've only tested it under Firefox 1.0.4, Internet Explorer (XP SP2),
K-Meleon 0.9 and Opera 7.23 (which made me assume that it also works for Opera
8, but I can't be sure about that). So, I think it works under the latest
version of FireFox, and probably for previous versions too (although not
tested). Do you get a JavaScript error or something similar? Keep in mind that
JavaScript should be enabled to be able to use this feature.

avarab wrote:

(In reply to comment #5)

Thanks for creating a patch file! I didn't know how to make one... Regarding the
testing, I've only tested it under Firefox 1.0.4, Internet Explorer (XP SP2),
K-Meleon 0.9 and Opera 7.23 (which made me assume that it also works for Opera
8, but I can't be sure about that). So, I think it works under the latest
version of FireFox, and probably for previous versions too (although not
tested). Do you get a JavaScript error or something similar? Keep in mind that
JavaScript should be enabled to be able to use this feature.

Turns out that the whole thing was just commented out (see patch) with <!-- -->,
works okey now except for the error with && being displayed as a literal (should
be &amp; or wrapped in a CDATA section).

dionyziz wrote:

The commenting is necessary, so that browsers that do not support JavaScript do
not display the client-side script source code inside the website. The HTML
comment tag is ignored by all browsers which support JavaScript when it is in
the first line of a <script> tag, so it is common to use it to avoid the problem
of displaying the source as text. Regarding the & entity, it shouldn't have been
escaped with &amp;, as it is used within the script code block, therefore not in
HTML. Javascript should handle this correctly and without any problems -- as far
as I know.

avarab wrote:

(In reply to comment #7)

The commenting is necessary, so that browsers that do not support JavaScript do
not display the client-side script source code inside the website. The HTML
comment tag is ignored by all browsers which support JavaScript when it is in
the first line of a <script> tag,

This is only true when you view the page in nonconformance mode, try sending it
with the application/xhtml+xml MIME type.

so it is common to use it to avoid the problem
of displaying the source as text. Regarding the & entity, it shouldn't have been
escaped with &amp;, as it is used within the script code block, therefore not in
HTML. Javascript should handle this correctly and without any problems -- as far
as I know.

& as a bareword is illegal unescaped and not within a CDATA block in XHTML/XML,
try sending it with the application/xhtml+xml MIME type, it will produce a fatal
parsing error.

dionyziz wrote:

(In reply to comment #8)

This is only true when you view the page in nonconformance mode, try sending it
with the application/xhtml+xml MIME type.
& as a bareword is illegal unescaped and not within a CDATA block in XHTML/XML,
try sending it with the application/xhtml+xml MIME type, it will produce a fatal
parsing error.

Alright, I'll look into it and supply a new patch file, then. Thanks for letting
me know about this :-)

dionyziz wrote:

(In reply to comment #8)

& as a bareword is illegal unescaped and not within a CDATA block in XHTML/XML,
try sending it with the application/xhtml+xml MIME type, it will produce a fatal
parsing error.

I've tried replacing the & entities with &amp; within the javascript code. The
initial code used to be:
if(o.wpRetype.value!=""&amp;&amp;(o.wpPassword.value!=o.wpRetype.value)){

Now it looks like this:
if(o.wpRetype.value!=""&amp;&amp;(o.wpPassword.value!=o.wpRetype.value)){

However, I get a Javascript parsing error after the replacement:
Error: missing ) after condition
if(o.wpRetype.value!=""&amp;&amp;(o.wpPassword.value!=o.wpRetype.value)){

Therefore, I am not posting a new patchfile, since the current one seems okay.
Ævar, if you could point out what I am doing wrong, it would be nice :-)

Thanks.

I don't think that's needed. I personally avoid javascript as much
as possible.

dionyziz wrote:

(In reply to comment #11)

I don't think that's needed. I personally avoid javascript as much
as possible.

If one does not prefer javascript, he or she can disable it from the browser
options. If javascript is disabled, the previous functionality of the plain HTML
login form will be available, just as it is on the current MediaWiki stable
release. On the other hand, if a user has javascript enabled, this will make
sure that a user that wants to create account and hits "Enter" by mistake after
re-entering the password and (optionally) Real Name and e-mail details will not
be logged in with his or her non-existing account. If that was the case, it
might have discouraged users from reattemping registeration, or confused
inexperienced users. As a sidenode, keep in mind that there is javascript
functionality embedded in the current stable version of MediaWiki, so there's no
need to avoid javascript in general.

Can someone please review this for inclusion in 1.5 ?

I would prefer to see our horrible combined login/create account form
completely redesigned into something humans can comprehend.

dionyziz wrote:

(In reply to comment #14)

I would prefer to see our horrible combined login/create account form
completely redesigned into something humans can comprehend.

You mean seperate the login and register form into two different pages?

login / creation have been split. Will be in 1.6

dionyziz wrote:

Thanks :-)