@mbabker I edited only uncompressed version of jQuery. I think it would be good to compress jQuery version to validate.js and change validate-uncompressed.js to validate-uncompressed-mootools.js or we can remove that.

I guess I added this jQuery version by mistake with my project PR.
#2015 is the PR open for replacing mootools version.

#2015 doesn't include precomputation of labels and if ($el.attr('required') || $el.hasClass('required')) {

Is this still valid or can it be closed?

@brianteeman I don't know if this is the same issue but I found that in 3.3 using IE <= 9 client side validation failed when there was a field with the validate-email class.

To replicate go to a page on the front end using a form prepared by JForm with an email input. The required is checked so text has to be entered but when the validate-email is set the following console error is generated:

SCRIPT438: Object doesn't support property or method 'toASCII'
validate-uncompressed.js, line 182 character 7

If the email field is left blank validation runs correctly and won't let the form be submitted but when the email address is entered the above error is generated and no validation is done.

If the validate-email class is removed for browsers less than IE 9 the error isn't thrown.

I just had a look in validate-uncompressed.js at the line 182 and it was this one:

value = punycode.toASCII(value);

but when I looked at punycode the actual method name is ToASCII (with a capital T) at the start. So maybe browsers > IE 9 are smart enough for this not be an issue.

I'll see if changing the validate-uncompressed.js script fix this on IE 9.

Eric.

This comment was created with the J!Tracker Application at http://issues.joomla.org/.

Sorry about spamming. Just had some free time. So yes changing validate-uncompressed.js at line 182 from:

value = punycode.toASCII(value);

to:

value = punycode.ToASCII(value);

meant that email address got correctly validated (not just required)on IE 9 and meant that the above error was no longer thrown and rest of form was validated correctly.

Should this be a PR against a different issue? For tracking purposes?

Also if so, do the compressed scripts get generated automatically from the uncompressed somewhere in the build process or should I also minify the script after changes have been made and overwrite the compressed version?

Sorry again for all the messages and I apologise if I have hijacked the wrong thread.

Eric.

This comment was created with the J!Tracker Application at http://issues.joomla.org/.

It doesn't sound like the same issue to me.
If possible can you create a Pull Request? It will automatically create a new issue then anyway.
See http://docs.joomla.org/Using_the_Github_UI_to_Make_Pull_Requests for how to create one if you never did before.

Make sure to include good testing instructions in the description of your PR.

Also if so, do the compressed scripts get generated automatically from the uncompressed somewhere in the build process or should I also minify the script after changes have been made and overwrite the compressed version?

It's not done automatically. So just compress it with your favorite compressing tool and add it to the PR.

Hi @Achal-Aggarwal

is this issue still valid? As the last comment here was on 27 Aug 2014? Also pull requests to the master branch of this repo are not longer accepted. Can you close this pull request and submit a new one against the staging branch, if this issue still exists?
If there is no response in a month we will close the PR here.

Thanks for understanding!

Closing this PR due to inactivity. If you still feel this is valid, the issue can be reopened. Thank you for your contribution.

Just ran into this issue when trying to diagnose why my Global Config wouldn't save.

Going by previous comments I found if I had an email address in the 'From email' form then the validation would try and run and the system would just hang. With the developer console open the code breaks in validate.js script at the function 'function(e,t){e=punycode.toASCII(e);var n=/^[a-zA-Z0-9.!#$%&’+\/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:.[a-zA-Z0-9-]+)$/;return n.test(e)}' right on the 'e=punycode.toASCII' call.

This may not give you more information but I just wanted to confirm that A) someone else had the issue and B) it is still valid in 3.4.0.

I apologise if this has since been sorted or there is another ticket open for it.

@RyanfaeScotland how much User groups do you have on your Site?
if there is a loot User Groups it can be a reason of system hang .. such performance issue you can test there #7460

Hi @Fedik thanks for the quick response.

I'd assume my User Groups are either 0, 1 or whatever the default is when Joomla is installed as I've never made explicit use of them. I can check for certain after work / over the weekend if you are interested?
Also happy to help get to the bottom of this. I've got a workaround of not having the email field filled so don't need an answer but happy to help if you (or anyone else) would like to investigate it.

Just repeated the process at home on my own PC and with IE 11.0.9600.18015 it still happens but using Chrome 45.0.2454.99 m there isn't any issue.

Hi Ryanfae,

Please add some steps how one can reproduce the issue at local.

On Sun, Sep 27, 2015 at 8:43 PM, RyanfaeScotland notifications@github.com
wrote:

Just repeated the process at home on my own PC and with IE 11.0.9600.18015
it still happens but using Chrome 45.0.2454.99 m there isn't any issue.

—
Reply to this email directly or view it on GitHub
#2233 (comment).

Achal

Will do @Achal-Aggarwal it may be a little while though as I don't have a local install and do all my work on my actual site. Been wanting to make a copy to local for a while though so will add it to my task list and report back when I get it done (if you never hear from me again assume I won the lottery and have decided never to touch a computer again).