Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-3452

Extra white area appears in Firefox when tabs display error messages

    Details

    • Similar issues:
      KULRICE-3119Error messages at the top of the maintenance.do page do not display properly in IE
      KULRICE-8770easyXDM issues with Firefox and Tomcat
      KULRICE-6604Progressive Disclosure highlighting doesn't allow disclosed items to have a background color other than white.
      KULRICE-6795krad.utility.js error message when adding PeopleFlow Members (in Firefox)
      KULRICE-7872Background color does not clear after refresh on Firefox
      KULRICE-1972Bad message shown when no error message is specified for validation on an eDocLite field
      KULRICE-4390Parital masking of value incorrectly displaying 1 extra unmasked character
      KULRICE-9838Collection Creates Extra Row
      KULRICE-7131Parameter Document - when a required field is left blank it generates an extra error message
      KULRICE-11292Validation messages on tree node components not displayed correctly
    • Rice Team:
      QA

      Description

      An easy way to reproduce this problem is to click on a "create new" link and then click "save" on the document. When the error messages get displayed in the relevant sections on the document, the messages displayed within a tab will add an extra line break (or something similar) that makes it seem like the tab has been split in two. I've only seen this problem in Firefox so far; IE does not have this problem.

      Fortunately, I believe I know where the problem lies. In KR-ApplicationResources.properties, I think I added the properties "errors.header" and "errors.footer" at around the time I was resolving an issue pertaining to the error messages at the top of maintenance document pages. Although these properties were not the fix for the specific problem I was solving, I had left them in so that the generated error messages would be outputted as valid HTML, since previously they were enclosed in <li> elements without any surrounding <ol> or <ul> elements. Removing these properties would be the easiest fix, but doing so could make the error messages get outputted as invalid HTML.

        Activity

        Hide
        Eric Westfall added a comment -

        Chad, what's your assessment of this, is it an easy quick fix with low risk is there going to need to be a bit of testing involved?

        Show
        Eric Westfall added a comment - Chad, what's your assessment of this, is it an easy quick fix with low risk is there going to need to be a bit of testing involved?
        Hide
        Eric Westfall added a comment -

        Marking fix version as 1.0.1 pending response from Chad.

        Show
        Eric Westfall added a comment - Marking fix version as 1.0.1 pending response from Chad.
        Hide
        Chad Hagstrom added a comment -

        I believe this is an easy problem to fix; my only concern with the solution I proposed was that the error messages could end up being displayed using invalid HTML, although this appears to be how they were being displayed before the addition of "errors.header" and "errors.footer". If HTML validity is a concern when fixing this issue, then, in addition to my proposed solution, the "errors.prefix" and "errors.suffix" properties can be changed to generate some other HTML element (such as a div) with a "display" CSS property of "list-item". Testing should not be difficult; we probably just need to verify that certain error messages relying on these properties are being displayed similarly to the way they were before the addition of the header and footer properties (namely, as list items with the square list bullets but without the indentation).

        Show
        Chad Hagstrom added a comment - I believe this is an easy problem to fix; my only concern with the solution I proposed was that the error messages could end up being displayed using invalid HTML, although this appears to be how they were being displayed before the addition of "errors.header" and "errors.footer". If HTML validity is a concern when fixing this issue, then, in addition to my proposed solution, the "errors.prefix" and "errors.suffix" properties can be changed to generate some other HTML element (such as a div) with a "display" CSS property of "list-item". Testing should not be difficult; we probably just need to verify that certain error messages relying on these properties are being displayed similarly to the way they were before the addition of the header and footer properties (namely, as list items with the square list bullets but without the indentation).
        Hide
        Eric Westfall added a comment -

        Thanks Chad, can you go ahead and apply the change this morning and do some testing on it to make sure it's good? If the HTML issue was present before, then I think it's ok. If you think there's something we need to revisit related to that later though, go ahead and create a 1.0.1 jira for it. Thanks!

        Show
        Eric Westfall added a comment - Thanks Chad, can you go ahead and apply the change this morning and do some testing on it to make sure it's good? If the HTML issue was present before, then I think it's ok. If you think there's something we need to revisit related to that later though, go ahead and create a 1.0.1 jira for it. Thanks!
        Hide
        Chad Hagstrom added a comment -

        I've corrected the problem by removing the header/footer properties and by changing the prefix/suffix property values to a <div> tag with appropriate "display" and "margin" CSS style settings. I've verified that the error messages are now displaying properly in both IE and Firefox; feel free to reopen this issue if anyone notices problems in other browsers.

        Show
        Chad Hagstrom added a comment - I've corrected the problem by removing the header/footer properties and by changing the prefix/suffix property values to a <div> tag with appropriate "display" and "margin" CSS style settings. I've verified that the error messages are now displaying properly in both IE and Firefox; feel free to reopen this issue if anyone notices problems in other browsers.
        Hide
        Eric Westfall added a comment -

        Bulk change of all Rice 1.0 issues to closed after public release.

        Show
        Eric Westfall added a comment - Bulk change of all Rice 1.0 issues to closed after public release.

          People

          • Assignee:
            Chad Hagstrom
            Reporter:
            Chad Hagstrom
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel