I have a few controls on the 2nd Tab of a WebTabPanel, and as I tab thru the running app the focus disappears to (what I suspect was) a control on the 1st Tab, then back to the 2nd Tab where the tab order continued as expected.
I went ahead and disabled the control on the 1st tab, then re-ran the app and then it started working fine, and seemed to confirm that was my tab issue.
However, when I re-enabled the control on 1st Tab and tried to replicate the issue, everything works now?! It’s as-if disabling and re-enableing that control knocked something loose.
Has anyone ran across this before? Is there a best-practice to follow when it comes to Tab orders on controls within a WebTabPanel?
I don’t have any Search Fields in this particular layout, and when I select my WebTextField in the IDE I don’t see all the same options you show in your screenshot - perhaps because subclassed WebTextField(?)
tab order works fine for desktop, but is incredingly strange under web app.
sometimes it works, and sometimes not.
I did not find any workaround for this sorry.
but you’re not alone !
My guess is that Emile didn’t see that this topic is under ‘Targets - Web’ and the comments are for Desktop.
I have seen this. I have seen something similar as the recent problem with Desktop (elsewhere on the forum) that Tab not working correctly but Shift+Tab works as expected.
Maybe there is a logic on the problem but is very hard to define/replicate to show Xojo the problem and them to fix it.
FWIW, When we designed the tab order logic for web 2, we were trying to balance what a desktop user would expect with what was possible on the supported browsers. There were some rules we tried to keep in mind:
focusable controls must be visible and enabled to accept focus
Tabbing should select the next control within the current WebView.
if the next “control” in the tab order is a subclass of WebView, control is transferred to that view and its first control receives focus.
if there is no “next” control in the view and the view is not a WebPage or a WebDialog, control is transferred to the view’s parent view and its “next” control gets focus.
if there is no “next” control and the view is a WebPage or a WebDialog, focus loops around to the first control on that view.
each view keeps track of the index of its currently focused control so that parenting thing will work.
Keep in mind that this should also work in reverse if the user is pressing SHIFT-TAB.
Accessibility
Lastly, an option was added just before I left Xojo to allow users to turn off the Xojo tab order engine for users who use screen readers or other accessibility tools. The only ones I see in autocomplete are Session.AllowTabOrderWrap and WebView.AllowTabOrderWrap which according to the docs is what they were renamed to although the name doesn’t fully represent what’s actually going on.
It should be set to False for webpages that will be used by users who depend on accessibility settings that allow them to tab to the browser’s toolbar controls.
Contrary to the documentation, my recollection is that this property is not completely “design-time only” and just needs to be set before the Opening event finishes on either WebSession or WebPage. @Ricardo_Cruz could clarify that for us.
In any case, it’s really important that you set the tab order if you’re using Xojo’s engine (the default).
TL;DR
In the end, I tried creating a WebDialog to test a theory and found that (at least on Mac) if you don’t have Full Keyboard Access turned on in your system preferences, buttons on the web layout do still get focus but they no longer change color. IIRC, they used to get slightly darker when they got focus, but I could be mis-remembering.
Edit: Apparently the focus color does work if there’s more than one button on the dialog.
@Greg_O I appreciate the breakdown of the logic. When you say ‘within the current WebView’ how does that apply to WebTabPanel? Is each ‘panel’ considered an independant WebView?
