Moodle
  1. Moodle
  2. MDL-19907

Mandatory fields accepting space as input

    Details

    • Database:
      MySQL
    • Testing Instructions:
      Hide

      1. Add a Glossary activity to a course (or use any other form that has both text and editor fields required) and try to enter spaces or line breaks in the required fields. - You should be able to save it. Please note that TinyMCE suppresses the single space by itself, try entering several spaces and line breaks in the editor field.
      2. Go to Site Administration->Security->Site policies and set the checkbox "Strict validation of required fields"
      3. repeat step 1 - spaces are now not allowed
      4. Run tests in lib/simpletest/testformslib.php

      Show
      1. Add a Glossary activity to a course (or use any other form that has both text and editor fields required) and try to enter spaces or line breaks in the required fields. - You should be able to save it. Please note that TinyMCE suppresses the single space by itself, try entering several spaces and line breaks in the editor field. 2. Go to Site Administration->Security->Site policies and set the checkbox "Strict validation of required fields" 3. repeat step 1 - spaces are now not allowed 4. Run tests in lib/simpletest/testformslib.php
    • Affected Branches:
      MOODLE_19_STABLE, MOODLE_20_STABLE
    • Fixed Branches:
      MOODLE_20_STABLE, MOODLE_21_STABLE
    • Pull Master Branch:
      wip-MDL-19907-master
    • Rank:
      2439

      Description

      In many of places in where moodle specifies a field ( input text field ) as mandatory, it is accepting "space" as a input and then proceeds without prompting,which results in an anonymous elements into the site or a course

      Steps to reproduce:

      Scenario 1:
      1. create a new course with space as course "full name" and with other details filled.

      Scenario 2 :
      1.Create a new user with some username and password with space as first name and lastname and city

      Actual Results :

      it is accepting "space" as a input and then proceeds without prompting,which results in an anonymous elements into the site or a course.

      Expected results :

      Space should be trimmed if its at the starting of any name or mandatory field, and if its not followed by any other valid characters the usual error highlighting should be done requesting the user to give valid inputs

      1. MDL-19907
        1 kB
        Mark Johnson
      2. MDL-19907_2.patch
        1 kB
        Mark Johnson
      3. testformslib.php
        4 kB
        Sam Hemelryk
      1. Course_error.png
        60 kB
      2. User_create_error.png
        63 kB

        Issue Links

          Activity

          Hide
          Mark Johnson added a comment -

          Patch adds trim() to PHP validation and uses .replace() for the same effect in javascript validation.

          Show
          Mark Johnson added a comment - Patch adds trim() to PHP validation and uses .replace() for the same effect in javascript validation.
          Hide
          Anthony Borrow added a comment -

          Petr - I was tempted simply to remove the "Could be a security issue" tag so that folks could watch/vote for the issue; however, I figured you might want to make that determination. I do not really see it as a security issue. I also considered dropping the priority to major as it does seem to allow for unintended behavior. Peace - Anthony

          Show
          Anthony Borrow added a comment - Petr - I was tempted simply to remove the "Could be a security issue" tag so that folks could watch/vote for the issue; however, I figured you might want to make that determination. I do not really see it as a security issue. I also considered dropping the priority to major as it does seem to allow for unintended behavior. Peace - Anthony
          Hide
          Mauno Korpelainen added a comment -

          I agree with Anthony - nameless users and courses ("space users") can be troublesome but not a security issue or critical bug.

          Mark promised to send soon a new patch with some extra tags ... http://moodle.org/mod/forum/discuss.php?d=131286

          Show
          Mauno Korpelainen added a comment - I agree with Anthony - nameless users and courses ("space users") can be troublesome but not a security issue or critical bug. Mark promised to send soon a new patch with some extra tags ... http://moodle.org/mod/forum/discuss.php?d=131286
          Hide
          Petr Škoda added a comment -

          I agree this is not a security issue, also I would not classify it as critical issue. No matter how hard we try there will always be ways to sneak in something invisible.

          I agree that spaces should trimmed before doing the emptiness test, I personally do not think we should test other characters because there will always be more of them and second sometimes the space workaround might be in fact valid solution of some problems - such as those annoying mandatory fields - people enter there rubbish anyway...

          In places where user is entering some critical information we have to cleanup the text manually and then verify the data on the server side - we do this already in several places.

          In anycase thanks for the report and ideas

          Show
          Petr Škoda added a comment - I agree this is not a security issue, also I would not classify it as critical issue. No matter how hard we try there will always be ways to sneak in something invisible. I agree that spaces should trimmed before doing the emptiness test, I personally do not think we should test other characters because there will always be more of them and second sometimes the space workaround might be in fact valid solution of some problems - such as those annoying mandatory fields - people enter there rubbish anyway... In places where user is entering some critical information we have to cleanup the text manually and then verify the data on the server side - we do this already in several places. In anycase thanks for the report and ideas
          Hide
          Mark Johnson added a comment -

          The new patch as promised - removes tags that could be added by the HTML editor while still only resulting in whitespace. I've tried it out, but it could probably use some more thorough testing - I'm sure there'll be a case or 2 I missed!

          Show
          Mark Johnson added a comment - The new patch as promised - removes tags that could be added by the HTML editor while still only resulting in whitespace. I've tried it out, but it could probably use some more thorough testing - I'm sure there'll be a case or 2 I missed!
          Hide
          Mark Johnson added a comment -

          Forgot to strip whitespace HTML entities as well - it's on it's way!

          Show
          Mark Johnson added a comment - Forgot to strip whitespace HTML entities as well - it's on it's way!
          Hide
          Mark Johnson added a comment -

          Having experimented with the HTML area, you can't use the WYSIWYG editor to add any whitespace HTML entities. Since the tags we resolved to strip are the ones that could be added by the HTML editor, it seems logical to follow the same pattern with HTML entities. Therefore, the second patch I've uploaded should be a sufficient fix.

          Show
          Mark Johnson added a comment - Having experimented with the HTML area, you can't use the WYSIWYG editor to add any whitespace HTML entities. Since the tags we resolved to strip are the ones that could be added by the HTML editor, it seems logical to follow the same pattern with HTML entities. Therefore, the second patch I've uploaded should be a sufficient fix.
          Hide
          Sam Marshall added a comment - - edited

          (Note: my view about this feature is that it is not really about 'preventing' people from posting empty things on purpose - there is no point as they could always just type 'x' anyhow and it is definitely not empty, but contains no content. It is about stopping people accidentally posting with empty things when they didn't realise they were supposed to fill them in, or perhaps making people think twice if they make a very half-hearted effort to get around a 'required' marker by hitting space a few times. Also note - I think we should reduce the use of required fields anyway, however there are some cases, such as a forum post without a message in it, which are pretty clear...)

          With regard to entities, this may depend on the editor in use. As Moodle 1.9 only supports one editor you might consider this sufficient.

          We use TinyMCE here and there are cases when it adds some kinds of nbsp etc (as per my code posted on forum). I wouldn't be against the code going in as is though.

          Regex looks to me like it should probably work, so if you have tested it, my +1 for committing. General code review notes:

          a) This is the same regex twice in JS/PHP. At a glance it looks identical, is this correct? If so it should ideally be defined as constant EMPTY_HTML_REGEX or somesuch and reused in both places in case a change is ever required. Comment for constant should warn that it will be used in both JS and PHP in case of possible syntax differences..

          b) In some places the regex uses ' ' (space) where it should probably be \s but this can probably be justified by 'the editor does it that way'.

          Show
          Sam Marshall added a comment - - edited (Note: my view about this feature is that it is not really about 'preventing' people from posting empty things on purpose - there is no point as they could always just type 'x' anyhow and it is definitely not empty, but contains no content. It is about stopping people accidentally posting with empty things when they didn't realise they were supposed to fill them in, or perhaps making people think twice if they make a very half-hearted effort to get around a 'required' marker by hitting space a few times. Also note - I think we should reduce the use of required fields anyway, however there are some cases, such as a forum post without a message in it, which are pretty clear...) With regard to entities, this may depend on the editor in use. As Moodle 1.9 only supports one editor you might consider this sufficient. We use TinyMCE here and there are cases when it adds some kinds of nbsp etc (as per my code posted on forum). I wouldn't be against the code going in as is though. Regex looks to me like it should probably work, so if you have tested it, my +1 for committing. General code review notes: a) This is the same regex twice in JS/PHP. At a glance it looks identical, is this correct? If so it should ideally be defined as constant EMPTY_HTML_REGEX or somesuch and reused in both places in case a change is ever required. Comment for constant should warn that it will be used in both JS and PHP in case of possible syntax differences.. b) In some places the regex uses ' ' (space) where it should probably be \s but this can probably be justified by 'the editor does it that way'.
          Hide
          Mauno Korpelainen added a comment -

          All good points - yet the original problem was not about using editor - it's about moodle accepting spaces to some normal manditory text input fields like First name, Surname and City or Course name - and unclickable links if we see a person "Space Space" or course "Whitespace".

          If somebody is so "stuped/clever" that he/she can select a name "Space Space" he/she can't afterwards click his/her name to open and edit profile because link is too short to be clicked. For tiny characters like '.' there is at least a tiny link line to be clicked. Administrator can always edit these accounts with Edit link and names of courses can be edited no matter how short they are.

          Personally I would not strip any characters - Stan Space is as acceptable as Stan alone (think about all those great artists, singers, football players...) and sometimes people like to be anonymous and use "rubbish names" but this link issue can be annoying and that's why I saw it as a bug.

          Show
          Mauno Korpelainen added a comment - All good points - yet the original problem was not about using editor - it's about moodle accepting spaces to some normal manditory text input fields like First name, Surname and City or Course name - and unclickable links if we see a person "Space Space" or course "Whitespace". If somebody is so "stuped/clever" that he/she can select a name "Space Space" he/she can't afterwards click his/her name to open and edit profile because link is too short to be clicked. For tiny characters like '.' there is at least a tiny link line to be clicked. Administrator can always edit these accounts with Edit link and names of courses can be edited no matter how short they are. Personally I would not strip any characters - Stan Space is as acceptable as Stan alone (think about all those great artists, singers, football players...) and sometimes people like to be anonymous and use "rubbish names" but this link issue can be annoying and that's why I saw it as a bug.
          Hide
          Mark Johnson added a comment -

          Sam, regarding your points:
          a) Very good point. Should the constant be defined in the same file, or somewhere else in /lib?
          b) \s matches any whitespace character, the places I've put a space are where it's actually looking for a space, not a tab or line break which may also be matched by \s.

          Show
          Mark Johnson added a comment - Sam, regarding your points: a) Very good point. Should the constant be defined in the same file, or somewhere else in /lib? b) \s matches any whitespace character, the places I've put a space are where it's actually looking for a space, not a tab or line break which may also be matched by \s.
          Hide
          Ravishankar Somasundaram added a comment -

          Patch works good, applied and tested..

          It covers the basic parameter check which will do good for now.

          Show
          Ravishankar Somasundaram added a comment - Patch works good, applied and tested.. It covers the basic parameter check which will do good for now.
          Hide
          Michael Blake added a comment -

          Reported as affecting a MP client. Please give priority.

          Show
          Michael Blake added a comment - Reported as affecting a MP client. Please give priority.
          Hide
          Chris Follin added a comment -

          Thanks for the patch. We successfully applied it to 1.9.11 and 2.0.3. Thank you, Michael, for adding 2.0.3 as an affected version.

          Show
          Chris Follin added a comment - Thanks for the patch. We successfully applied it to 1.9.11 and 2.0.3. Thank you, Michael, for adding 2.0.3 as an affected version.
          Hide
          Marina Glancy added a comment -

          Eloy, Petr,

          since this issue is going to be finally fixed now, there are a couple of things to decide:
          1. the simplest solution would be to alter the code of HTML_QuickForm. Otherwise the code can become complicated. Is it acceptable?
          2. can we assume that ANY tag (except img, hr, canvas) can be stripped from the input in order to validate 'required' rule?
          Thanks

          Show
          Marina Glancy added a comment - Eloy, Petr, since this issue is going to be finally fixed now, there are a couple of things to decide: 1. the simplest solution would be to alter the code of HTML_QuickForm. Otherwise the code can become complicated. Is it acceptable? 2. can we assume that ANY tag (except img, hr, canvas) can be stripped from the input in order to validate 'required' rule? Thanks
          Hide
          Marina Glancy added a comment -

          There is the way to override the 'required' check without altering HTML_QuickForm, so the first question no longer needs answer

          Show
          Marina Glancy added a comment - There is the way to override the 'required' check without altering HTML_QuickForm, so the first question no longer needs answer
          Hide
          Andrew Davis added a comment - - edited

          It looks fine although is the addition of $CFG->strictformsrequired really required? If it's required then it's required however if we can avoid adding a "actually enforce the rules" config flag that would be nice.

          The php docs for getValidationScript() are missing an @param.

          In the php docs for validate() lines like "@access public" don't really add anything and can be removed.

          Are there unit tests for QuickForm validation? If so you should add some that define the expected behavior of this new code. If not, well, it would be nice to see some created. Any time there are regular expressions its nice to see a set of tests that define what its meant to be doing.

          Show
          Andrew Davis added a comment - - edited It looks fine although is the addition of $CFG->strictformsrequired really required? If it's required then it's required however if we can avoid adding a "actually enforce the rules" config flag that would be nice. The php docs for getValidationScript() are missing an @param. In the php docs for validate() lines like "@access public" don't really add anything and can be removed. Are there unit tests for QuickForm validation? If so you should add some that define the expected behavior of this new code. If not, well, it would be nice to see some created. Any time there are regular expressions its nice to see a set of tests that define what its meant to be doing.
          Hide
          Marina Glancy added a comment -
          • rewrote validation for required fields in forms, including support for editor field.
          • Added parameter to use strict (no spaces) required fields validation (for compatibility with the existing users who used spaces in required fields on purpose)
          • removed hack for 'editor' field added in 2.x
          Show
          Marina Glancy added a comment - rewrote validation for required fields in forms, including support for editor field. Added parameter to use strict (no spaces) required fields validation (for compatibility with the existing users who used spaces in required fields on purpose) removed hack for 'editor' field added in 2.x
          Hide
          Aparup Banerjee added a comment -

          Hi Marina,
          i had done a review of this half-way before i was away for awhile- so just adding my 2c here (seems to still apply):
          1) 'Strict required fields validation' would make better sense to me with 'Trim surrounding whitespace from input'. (Can always ask Helen for input on strings)

          2) HTML_QuickForm_Rule::validate($value) but MoodleQuickForm_Rule_Required::validate($value, $options = null) and '$options Not used yet' seems like we don't need $options at all?

          Show
          Aparup Banerjee added a comment - Hi Marina, i had done a review of this half-way before i was away for awhile- so just adding my 2c here (seems to still apply): 1) 'Strict required fields validation' would make better sense to me with 'Trim surrounding whitespace from input'. (Can always ask Helen for input on strings) 2) HTML_QuickForm_Rule::validate($value) but MoodleQuickForm_Rule_Required::validate($value, $options = null) and '$options Not used yet' seems like we don't need $options at all?
          Hide
          Marina Glancy added a comment -

          Helen,

          can you suggest the good name for the parameter.
          Right now the strings are:
          $string['strictformsrequired'] = 'Strict required fields validation';
          $string['configstrictformsrequired'] = 'Do not allow spaces or other invisible entities in required fields in forms.';

          Thank you

          Show
          Marina Glancy added a comment - Helen, can you suggest the good name for the parameter. Right now the strings are: $string ['strictformsrequired'] = 'Strict required fields validation'; $string ['configstrictformsrequired'] = 'Do not allow spaces or other invisible entities in required fields in forms.'; Thank you
          Hide
          Petr Škoda added a comment -

          We have lived with this known issue for many years and suddenly it is a blocker that should be backported even to 1.9.x? I do not like this change much, especially the new setting. I believe developers should decide if space is ok or not, that would probably require a new type of rule which would mean it would go into 2.2dev only.

          We are dealing with html and there will always be a way to create something invisible, if somebody does not want to disclose for example the city they will put random rubbish there anyway. In other places like course shortname or idnumbers we should be probably doing a lot more than verifying emptiness (such as trimming whitespace).

          my -1

          Show
          Petr Škoda added a comment - We have lived with this known issue for many years and suddenly it is a blocker that should be backported even to 1.9.x? I do not like this change much, especially the new setting. I believe developers should decide if space is ok or not, that would probably require a new type of rule which would mean it would go into 2.2dev only. We are dealing with html and there will always be a way to create something invisible, if somebody does not want to disclose for example the city they will put random rubbish there anyway. In other places like course shortname or idnumbers we should be probably doing a lot more than verifying emptiness (such as trimming whitespace). my -1
          Hide
          Petr Škoda added a comment -

          Maybe it would be best to leave this open until Eloy returns from his vacation, thanks in any case!

          Show
          Petr Škoda added a comment - Maybe it would be best to leave this open until Eloy returns from his vacation, thanks in any case!
          Hide
          Sam Hemelryk added a comment -

          I've been having a look and a think about this issue at the conference today and have a few thoughts.
          I agree with Petr on many of the points he raised, and in fact I think some of them Marina and myself had discussed.
          Certainly people will soon learn that a space no longer fools a required field, and of course they will just start entering rubbish.
          I also think Petr is spot on in noting that really the only way to solve this is to improve the validation that on specific fields, and likely the best way to achieve this is to add rules where required to allow us to easily improve those areas.
          At the same time I don't think the new setting is all that awful, certainly it provides a global solution to at least tighten the rules.
          All that being said I haven't had time to go through and properly review this code in context.
          I'm going to reopen this shortly and will endeavor to take a proper look at it when I'm back in Perth, plus bring it up at the weekly meeting.
          For the mean time a couple of small notes:

          • Code formatting for class and method definitions in lib/formslib.php needs to be fixed. Opening braces should be on the definition line.
          • The regular expressions can be improved, and certainly need to more testing.
          • It would be great (if possible) to include unit tests for the rule.

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - I've been having a look and a think about this issue at the conference today and have a few thoughts. I agree with Petr on many of the points he raised, and in fact I think some of them Marina and myself had discussed. Certainly people will soon learn that a space no longer fools a required field, and of course they will just start entering rubbish. I also think Petr is spot on in noting that really the only way to solve this is to improve the validation that on specific fields, and likely the best way to achieve this is to add rules where required to allow us to easily improve those areas. At the same time I don't think the new setting is all that awful, certainly it provides a global solution to at least tighten the rules. All that being said I haven't had time to go through and properly review this code in context. I'm going to reopen this shortly and will endeavor to take a proper look at it when I'm back in Perth, plus bring it up at the weekly meeting. For the mean time a couple of small notes: Code formatting for class and method definitions in lib/formslib.php needs to be fixed. Opening braces should be on the definition line. The regular expressions can be improved, and certainly need to more testing. It would be great (if possible) to include unit tests for the rule. Cheers Sam
          Hide
          Marina Glancy added a comment -

          Martin approved the new setting.
          Code is slightly reformatted and branch for 2.1 is created

          Show
          Marina Glancy added a comment - Martin approved the new setting. Code is slightly reformatted and branch for 2.1 is created
          Hide
          Sam Hemelryk added a comment -

          Hi Marina,
          Just I've just been looking at this now and have picked up a few things:

          1. This new setting should be off by default. We don't want to force people to use the new strict required rule, we just to give them the option.
          2. Checks for $CFG->strictformsrequired should either be !empty($CFG->strictformsrequired) or there should be something to trigger upgrade (I didn't trigger upgrade and got a pile of notices... our testers will be in the same boat).
          3. The JavaScript regular expression can be simplified to /^\s+$/ there's no need to for the pipe we only need to know if the string is empty.
          4. The $stripvalues regular expression for whitespace doesn't need to specify \n, \f, \t, \r these are covered by \s.
          5. In that same regex you have \xc2 which appears to be Â... is that meant to be there?
          6. lib/pear/README_MOODLE.txt needs to be updated to reflect the removal of that editor hack.
          7. Could you please squash the minor commits on this branch into a single commit for integration, or alternativily squash the whole branch into a single commit. The commit message `formatting` could be improved by the way
          8. I'll attach a set of simpletest file that you can have a look at and add to the solution if you like.

          On a general note:

          We won't be backporting this to MOODLE_19_STABLE, only the 2+ branches.
          The reason for this is that at this point this is as much a new feature as it is a bug fix, and we are only backporting major bug fixes or security bugfixes to 1.9 presently (keeping it VERY stable).

          The way in which the validate function checks for an array containing a key of 'text' without checking the element is an editor is certainly step down from the previous hack, however I don't think that there is much that can be done about that without huge changes (required can hardly be considered a rule, and each element should have the ability to decide whether its `requirements` have been met).
          I don't think this requires action just noting it here.

          The final thing to mention is that we need to investigate where people are using array names for their form elements and whether or not we can improve this rule to deal with those. For example I created a test for that had a multi select element to which an array was passed to the rules validate function. Technically no more broken than the old rule is presently.

          Sending this back around again this week so that those can be tidied up, they're all pretty trivial but let me know if you have any questions.

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Hi Marina, Just I've just been looking at this now and have picked up a few things: This new setting should be off by default. We don't want to force people to use the new strict required rule, we just to give them the option. Checks for $CFG->strictformsrequired should either be !empty($CFG->strictformsrequired) or there should be something to trigger upgrade (I didn't trigger upgrade and got a pile of notices... our testers will be in the same boat). The JavaScript regular expression can be simplified to /^\s+$/ there's no need to for the pipe we only need to know if the string is empty. The $stripvalues regular expression for whitespace doesn't need to specify \n, \f, \t, \r these are covered by \s. In that same regex you have \xc2 which appears to be Â... is that meant to be there? lib/pear/README_MOODLE.txt needs to be updated to reflect the removal of that editor hack. Could you please squash the minor commits on this branch into a single commit for integration, or alternativily squash the whole branch into a single commit. The commit message `formatting` could be improved by the way I'll attach a set of simpletest file that you can have a look at and add to the solution if you like. On a general note: We won't be backporting this to MOODLE_19_STABLE, only the 2+ branches. The reason for this is that at this point this is as much a new feature as it is a bug fix, and we are only backporting major bug fixes or security bugfixes to 1.9 presently (keeping it VERY stable). The way in which the validate function checks for an array containing a key of 'text' without checking the element is an editor is certainly step down from the previous hack, however I don't think that there is much that can be done about that without huge changes (required can hardly be considered a rule, and each element should have the ability to decide whether its `requirements` have been met). I don't think this requires action just noting it here. The final thing to mention is that we need to investigate where people are using array names for their form elements and whether or not we can improve this rule to deal with those. For example I created a test for that had a multi select element to which an array was passed to the rules validate function. Technically no more broken than the old rule is presently. Sending this back around again this week so that those can be tidied up, they're all pretty trivial but let me know if you have any questions. Cheers Sam
          Hide
          Sam Hemelryk added a comment -

          Sorry nearly forgot to attach this!

          Show
          Sam Hemelryk added a comment - Sorry nearly forgot to attach this!
          Hide
          Helen Foster added a comment -

          Marina, thanks for adding me as a watcher. My suggestions for the new lang strings are:

          $string['strictformsrequired'] = 'Strict validation of required fields';
          $string['configstrictformsrequired'] = 'If enabled, users are prevented from entering a space or line break only in required fields in forms.';

          Show
          Helen Foster added a comment - Marina, thanks for adding me as a watcher. My suggestions for the new lang strings are: $string ['strictformsrequired'] = 'Strict validation of required fields'; $string ['configstrictformsrequired'] = 'If enabled, users are prevented from entering a space or line break only in required fields in forms.';
          Hide
          Marina Glancy added a comment -

          This is considered more like an improvement than a bug. 1.9 will not be changed.

          In 2.0+ there is a new setting "Strict validation of required fields" (Helen, thanks for suggestion of the name for it). It is off by default. Administrator can set it to disallow spaces or other invisible input in the required fields.

          Show
          Marina Glancy added a comment - This is considered more like an improvement than a bug. 1.9 will not be changed. In 2.0+ there is a new setting "Strict validation of required fields" (Helen, thanks for suggestion of the name for it). It is off by default. Administrator can set it to disallow spaces or other invisible input in the required fields.
          Hide
          Marina Glancy added a comment -

          Sam, thanks very much for your comment by the way. I agree with everything except #5:
          In that same regex you have \xc2 which appears to be Â... is that meant to be there?

          For some reason when user enters several consecutive spaces in the editor field, TinyMCE replaces them with symbols with codes c2 and a0.

          Show
          Marina Glancy added a comment - Sam, thanks very much for your comment by the way. I agree with everything except #5: In that same regex you have \xc2 which appears to be Â... is that meant to be there? For some reason when user enters several consecutive spaces in the editor field, TinyMCE replaces them with symbols with codes c2 and a0.
          Hide
          Sam Hemelryk added a comment -

          Hi Marina,

          No probs thanks for clarifying why  is being added to the page.
          I can understand why they are adding \xa0 as that is a non breaking space but \xc2 seemed like it was out of left field, perhaps they just couldn't find a character to meet their need

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Hi Marina, No probs thanks for clarifying why  is being added to the page. I can understand why they are adding \xa0 as that is a non breaking space but \xc2 seemed like it was out of left field, perhaps they just couldn't find a character to meet their need Cheers Sam
          Hide
          Sam Hemelryk added a comment -

          Thanks guys, this has now been integrated

          Show
          Sam Hemelryk added a comment - Thanks guys, this has now been integrated
          Hide
          Michael de Raadt added a comment -

          Tested with spaces and newlines. I found that required text fields would not accept spaces only, regardless of the global setting for strictness. For editors, I was able to get it to accept newlines and spaces as an input in a required field while the strict setting was off, but turning it on prevented this.

          Ran the unit tests. All passed.

          Integration test = passed

          Show
          Michael de Raadt added a comment - Tested with spaces and newlines. I found that required text fields would not accept spaces only, regardless of the global setting for strictness. For editors, I was able to get it to accept newlines and spaces as an input in a required field while the strict setting was off, but turning it on prevented this. Ran the unit tests. All passed. Integration test = passed

            People

            • Votes:
              2 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: