Details

    • Type: Sub Task Sub Task
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0.3
    • Component/s: Development
    • Labels:
      None
    • Similar issues:
      KULRICE-4759Starting tabindex at 0 causes problems in Lookup framework
      KULRICE-11786AFT Failure No values match this search no longer displayed in many tests, DemoLookUpOperatorsAft too, plus commas added to input fields
      KULRICE-9867Popover form no longer working
      KULRICE-10003Close button on popover form does not work in IE
      KULRICE-4371Look into why Attribute Lookups do not post values back to form
      KULRICE-13032AFT Failure KRAD No values match this search no longer displayed
      KULRICE-9975Lookups from within lookups no longer return values correctly
      KULRICE-11204Add option to disable back button support (adding form and cache key)
      KULRICE-13030AFT Failure RoleGroupPermissionResponsibilityTypeAft No values match this search no longer displayed
      KULRICE-4809should be able to customize button text in edoclite
    • Rice Module:
      KNS
    • Application Requirement:
      KFS
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      It seems that the tabindex values must have been removed from document buttons at some point. This is causing strange (from a power-user's standpoint) behavior in tabbing order. In WebKit-based browsers, you tab through all the fields, then through all the buttons with tabindex values, then it finally gets to the "zero" entries which include the buttons at the bottom. In firefox, It mostly seems to do the same thing, except that it only tabs through the show/hide buttons, never through the lookup buttons.

      We need to get the control buttons set somewhere between the fields and the other links/buttons on the page.

      Fields start at 1
      Other buttons start at 1000000 (initially - this seems to be a persistent counter - at least within a session)

      Firefox has a setting which may control what it can tab through. I have it set to tab through everything, which is the default on non-OS X machines.

      http://kb.mozillazine.org/Accessibility.tabfocus

      1. documentControls.tag.patch
        11 kB
        Jonathan Keller
      2. proposed_tabindex_fix.patch
        24 kB
        Jonathan Keller
      3. tab_order.patch
        37 kB
        Jeremy Hanson
      1. screenshot-1.jpg
        129 kB

        Activity

        Hide
        Jonathan Keller added a comment -

        This isn't being helped by inconsistencies in how browsers are handling tabindex. I just tried to fix this locally with the attached patch. While, logically, this should have fixed it, it did not. The tab order went to the 1000000 entries first, and then to the 990000 entries.

        Is there a reason we are attempting to set tab order rather than letting the natural order of the page prevail?

        Show
        Jonathan Keller added a comment - This isn't being helped by inconsistencies in how browsers are handling tabindex. I just tried to fix this locally with the attached patch. While, logically, this should have fixed it, it did not. The tab order went to the 1000000 entries first, and then to the 990000 entries. Is there a reason we are attempting to set tab order rather than letting the natural order of the page prevail?
        Hide
        Jonathan Keller added a comment -

        So - I experimented with the framework and removed the taborders (reset to zero).

        This made the maintenance document work the way I would expect. You set all "normal" fields and buttons to zero and all other controls which you don't want in the tab order to -1. This created the proper flow once the focus was within the form.

        Show
        Jonathan Keller added a comment - So - I experimented with the framework and removed the taborders (reset to zero). This made the maintenance document work the way I would expect. You set all "normal" fields and buttons to zero and all other controls which you don't want in the tab order to -1. This created the proper flow once the focus was within the form.
        Hide
        Jonathan Keller added a comment -

        I just attached a patch which seems to take care of most of the maintenance document issues. It zeroes out the tab order on maintenance document fields and sets the tabindex on most control buttons to -1 with the exception of the document controls at the bottom.

        Show
        Jonathan Keller added a comment - I just attached a patch which seems to take care of most of the maintenance document issues. It zeroes out the tab order on maintenance document fields and sets the tabindex on most control buttons to -1 with the exception of the document controls at the bottom.
        Hide
        Jeremy Hanson added a comment -

        Just as a note, I don't see where these ever had a tabindex value.

        Show
        Jeremy Hanson added a comment - Just as a note, I don't see where these ever had a tabindex value.
        Hide
        Jonathan Keller added a comment -

        Which means, it must have been a change to the form fields which caused this. But, I thought we had had the tabindex in the maintenance documents (rowDisplay.tag) for quite some time.

        Show
        Jonathan Keller added a comment - Which means, it must have been a change to the form fields which caused this. But, I thought we had had the tabindex in the maintenance documents (rowDisplay.tag) for quite some time.
        Hide
        Jeremy Hanson added a comment -

        It looks like the tabindex in rowDisplay.tag is new for 1.0.3. Looks like it was added in svn revision 14168, for KULRICE-4279.

        Show
        Jeremy Hanson added a comment - It looks like the tabindex in rowDisplay.tag is new for 1.0.3. Looks like it was added in svn revision 14168, for KULRICE-4279 .
        Hide
        Jeremy Hanson added a comment -

        Added tab_order.patch patch.

        Show
        Jeremy Hanson added a comment - Added tab_order.patch patch.

          People

          • Assignee:
            Unassigned
            Reporter:
            Jonathan Keller
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel