Enterprise: IE Issue: tabbing in a dialog with lots of fields takes extra time between tabbing.

Created on 5 Aug 2019  路  4Comments  路  Source: infor-design/enterprise

Describe the bug
IE tabbing is very slow in a modal dialog. We've tracked this down to modal.js getTabbableElements which is called each time a tab event is handled. The find seems to take an inordinate amount of time for modals with a lot of fields.

  getTabbableElements() {
    const allTabbableElements = $(this.element).find('a[href], area[href], input:not([disabled]),' +
      'select:not([disabled]), textarea:not([disabled]),' +
      'button:not([disabled]), iframe, object, embed, *[tabindex],' +
      '*[contenteditable]').filter(':visible');
    return {
      first: allTabbableElements[0],
      last: allTabbableElements[allTabbableElements.length - 1]
    };
  },

To Reproduce
Steps to reproduce the behavior:

  1. Open IE and Go to https://usspvwlmclient1.infor.com/hcm/Administration/page/ResourceSearchPage?csk.ng=true&menu=LRCResources.Resources
  2. In the app menu Click on Resources > Hire Resource
  3. Once the dialog comes up start tabbing between fields and notice how sluggish it feels.

Expected behavior
Should tab as quickly as other browsers

4.20

[3] focus critical landmark type

Most helpful comment

Some ideas for Modal.prototype.getTabbableElements():

  • use document.querySelectorAll() instead of jQuery.find()
  • the current internal use of the method isn't really efficient, in the sense that a new giant DOM query has to happen any time the keypress goes off. We should probably change this to do these:

    • store a cached list of tabbable elements whenenver the modal opens. It could use this same method to initially grab the elements.

    • provide a trigger method for that regenerates that list via the Modal API. I'm thinking that would be useful for cases where there might be multiple screens or really dynamic bits of content in a modal.

All 4 comments

Some ideas for Modal.prototype.getTabbableElements():

  • use document.querySelectorAll() instead of jQuery.find()
  • the current internal use of the method isn't really efficient, in the sense that a new giant DOM query has to happen any time the keypress goes off. We should probably change this to do these:

    • store a cached list of tabbable elements whenenver the modal opens. It could use this same method to initially grab the elements.

    • provide a trigger method for that regenerates that list via the Modal API. I'm thinking that would be useful for cases where there might be multiple screens or really dynamic bits of content in a modal.

Thinking to run the caching off dom element count (if fast enough)

Just wanted to make a note on this issue (i know its app developers doing what they do). But this form has 271 inputs on it. Which is a bit overwhelming for cognitive load. It's only going to be so fast on IE11 as there DOM rendering is very slow so i can see further issues coming up with the pattern.

I suggest max 10 things on a modal. This should perhaps be a drill in page in the SPA and perhaps with multiple pages from that page to cover all the data inputing not just a 270 item form. The PR speeds things up but i can guarantee there will be other issues with a huge modal like this especially in IE 11.

Was this page helpful?
0 / 5 - 0 ratings