When you are viewing a ticket there are various editable fields (e.g. Priority, Dept, Due Date) that, when clicked, invoke a popup modal.

It would be nice if the Agent could immediately start interacting with the popup using his or her keyboard to select radio buttons, tab to the next item, type content into fields, etc.

But unfortunately the focus is still on the parent page underneath the popup. The Agent must click somewhere in the popup for it to be in focus.

Has anyone come up with a tweak to automatically set focus on these modals?

@KevinTheJedi do you know if there is a technical reason why this isn't already the case?

  • KevinTheJedi replied to this.

  • stevland

    Not any particular reason (that I know of). I will say that the current legacy codebase is almost entirely hand-written (by purely backend developers 😅) so some front-end/accessibility features such as this were skipped over, not known at the time, we didn't have time to focus on, we didn't really care about at the time, etc.

    I agree, for some fields and instances auto-focus is great to have like inline edit popups with dropdown fields, text fields, etc. but in other cases it's irrelevant or not needed, etc. So we would need a big overhaul to have the ability to allow certain fields/popups and reject others as there are a lot of different forms and field types that would need modifying as well as many different popup templates. So at this point it's just not worth our time and effort as we are trying to mainly focus on v2.0 to get it done and released asap (it's long awaited).

    With this being said, you are more than welcome to take a stab at it however you'd need to take into account every single form/field/popup/etc. and all edge cases and also not break anything else and have the ability to disable it per agent, etc... it's a LOT to think about and change. 😅

    v2.0 will have such capabilities. We are also spending more time on accessibility features (for screen-readers, keyboard users, etc.) from the get-go in v2.0.

    Cheers.

      stevland

      Not any particular reason (that I know of). I will say that the current legacy codebase is almost entirely hand-written (by purely backend developers 😅) so some front-end/accessibility features such as this were skipped over, not known at the time, we didn't have time to focus on, we didn't really care about at the time, etc.

      I agree, for some fields and instances auto-focus is great to have like inline edit popups with dropdown fields, text fields, etc. but in other cases it's irrelevant or not needed, etc. So we would need a big overhaul to have the ability to allow certain fields/popups and reject others as there are a lot of different forms and field types that would need modifying as well as many different popup templates. So at this point it's just not worth our time and effort as we are trying to mainly focus on v2.0 to get it done and released asap (it's long awaited).

      With this being said, you are more than welcome to take a stab at it however you'd need to take into account every single form/field/popup/etc. and all edge cases and also not break anything else and have the ability to disable it per agent, etc... it's a LOT to think about and change. 😅

      v2.0 will have such capabilities. We are also spending more time on accessibility features (for screen-readers, keyboard users, etc.) from the get-go in v2.0.

      Cheers.

        Thanks for the verbose explaination, Kev.

        Indeed, after I read this Stack Overflow page I realized there are far more considerations to setting focus on a modal then I ever would have imagined... and that's without the complexity of osTicket!

        It would have been a nice tweak, but it's definitely not worth obsessing over at this point.

        I'm very stoked to learn that you guys are actively developing v2.0!

        That is exciting.

        Write a Reply...