Last modified: 2011-03-09 21:14:51 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 2449 - Login form small visual improvement
Login form small visual improvement
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
1.5.x
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Dionysis Zindros
: patch, patch-need-review
Depends on:
Blocks: javascript
  Show dependency treegraph
 
Reported: 2005-06-18 19:32 UTC by Dionysis Zindros
Modified: 2011-03-09 21:14 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Userlogin.php (4.92 KB, text/plain)
2005-06-18 19:33 UTC, Dionysis Zindros
Details
Userlogin.php patch (3.55 KB, patch)
2005-06-24 03:44 UTC, Ævar Arnfjörð Bjarmason
Details

Description Dionysis Zindros 2005-06-18 19:32:26 UTC
Hello,

I've been working on a small visual improvement on the login/registration form
of MediaWiki (MediaWiki 1.5 CVS). I wrote a small JS script, which
disables/enables the "Login" and "Create new account" buttons accordingly; for
example, you are not allowed to click on "Create new account" if you haven't
filled in the "retype password" field. What's more, the code checks if the two
passwords match before the form is sent to the server, and displays a message if
they don't (and also cancels the navigation process and clears the password
fields). If javascript is disabled, the pages will work normally, as they would
without my code. The only file I modified is /include/templates/Userlogin.php.
Since I don't have CVS write access, I am submitting the modified file here. If
it is possible, I would appreciate it if one of you developers with read/write
CVS access can take a few minutes to check my code and CVS commit the file. I am
attaching the patch file in this bugzilla tracker item. Please let me
know if there's something you don't like, or something you'd like me to add, and
please let me know if and when you include my changes to the CVS (or if you
don't, the reasons why you won't)

Thank you in advance :-)
Dionysis Zindros.
Comment 1 Dionysis Zindros 2005-06-18 19:33:03 UTC
Created attachment 617 [details]
Userlogin.php
Comment 2 Ævar Arnfjörð Bjarmason 2005-06-24 01:17:57 UTC
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;)
Comment 3 Ævar Arnfjörð Bjarmason 2005-06-24 03:44:21 UTC
Created attachment 641 [details]
Userlogin.php patch
Comment 4 Ævar Arnfjörð Bjarmason 2005-06-24 03:47:33 UTC
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?
Comment 5 Dionysis Zindros 2005-06-26 10:37:57 UTC
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.
Comment 6 Ævar Arnfjörð Bjarmason 2005-06-26 10:55:35 UTC
(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).
Comment 7 Dionysis Zindros 2005-06-26 11:33:59 UTC
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.
Comment 8 Ævar Arnfjörð Bjarmason 2005-06-26 11:39:10 UTC
(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.
Comment 9 Dionysis Zindros 2005-06-26 11:44:16 UTC
(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 :-)
Comment 10 Dionysis Zindros 2005-06-26 20:50:49 UTC
(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.
Comment 11 Antoine "hashar" Musso (WMF) 2005-07-12 20:19:53 UTC
I don't think that's needed. I personally avoid javascript as much
as possible.
Comment 12 Dionysis Zindros 2005-07-13 15:49:31 UTC
(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.
Comment 13 Antoine "hashar" Musso (WMF) 2005-07-13 15:51:32 UTC
Can someone please review this for inclusion in 1.5 ?
Comment 14 Brion Vibber 2005-07-13 19:58:23 UTC
I would prefer to see our horrible combined login/create account form 
completely redesigned into something humans can comprehend.
Comment 15 Dionysis Zindros 2005-07-13 22:38:53 UTC
(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?
Comment 16 Antoine "hashar" Musso (WMF) 2006-01-08 13:55:14 UTC
login / creation have been split. Will be in 1.6
Comment 17 Dionysis Zindros 2006-01-08 21:27:26 UTC
Thanks :-)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links