PowerApps: "Fixing" Tab order

Yet again, PowerApps does not fail to disappoint in how certain basic things function while continuing to perform feats of magic on the back-end.

It is best to laugh when you encounter these little glitches, note them, and then quickly not brood over exactly how dumb someone had to be to miss X.

This article deals w/ Tab order and some of the issues you'll encounter

So Tab order is pretty straightforward in virtually every environment.  For the novice, this is when you hit Tab or Alt-Tab while moving through a series of fields/controls.  It is just basic plumbing that just works w/o consideration.  Except here.

For the most part, your assumptions are correct.  The values of TabIndex on a control apply as follows:

• -1 : Never visit this control
• 0 : Default
• 1,2,3,10...100 : Ascending order of movement

Out of the box, you'd also expect that PowerApps would probably even auto-populate TabIndex based on location or order of placement into a Form.  You'd also only be partially right.  You'd also want to punch someone for how much that word "partially" doesn't cover what happens.

Defaults and Concerns

From my experience, in all cases all fields default to Zero (0).  However, the treatment of "which Zero" comes next can be strange at best.  In particular, if you have created an Edit Form and linked it to a data source.  One of the first things you'll do is start moving fields around on the page and that's when Tab order gets...wonky.

You might believe that PowerApps set your TabIndex field for you (supposedly the ultimate arbiter of Tab order).  It didn't.  It just kinda did some magic behind the scenes of how it thought you wanted things and then hid all of that logic from you.  Which, IMHO, is far worse that just defaulting the order.  Particularly in that it sometimes causes the first issue I note in the Troubleshooting section below.

In practice, fields with identical values of TabIndex should probably move left->right, top->bottom along the screen for identical TabIndex values.  And perhaps, that is how the application works...initially.  However, when you start moving fields around then the order can become completely screwed up even when you're sitting there staring at TabIndex values that are clearly correct (e.g. you renamed them to 1,2,3...).

NOTE: During a retest in 2023, it appears Microsoft is setting the TabIndex on certain "unlikely for you to expect to tab to" controls to -1 by default, but any normal control is still set to 0. 

Rules

The order of 1, 2, 3 or 3, 2, 1 for Tab/Alt-Tab is correct.  It works.  If it isn't working for you, then see the "Troubleshooting" section below.  

If numbers are "missing" then the application skips it and moves to the next highest number.

If numbers are identical then...something...something...happens.  See Troubleshooting.

Best Practices

I've found the following tricks to be "best practice" in my own experience.  YMMV.

No Zeroes

No TabIndex = 0 controls.  Just take them out immediately.  Set it to -1 if you aren't sure what to do yet.  If you have any controls on your page w/ Zero values then things can (will) get weird.

Standardize on high-value TabIndex for common controls

I set the Tab Order on my "standard controls" quite high and in order.  So whenever I'm done w/ "whatever else" is on my page/form, I'll eventually wind up at Tab 100 which is one of the core form controls (e.g. Cancel, Back, Next).

Change the TabIndex along with the Visible property

I also reset any non-visible field's TabIndex value to be -1.  For example for an Edit Form I might have the following value in TabIndex for the input text field:

• If(Parent.visible,1,-1) (or alternatively)
• If(Self.visible, 1, -1)

That's an "if" statement looking to see if the property of the "Parent" control (that is the DataCard in the case of a form control) is true or false and setting the TabIndex to be either 1 or -1 respectively.  I do similar things for Popups.

Is this necessary?  I have no idea, but some very strange things are going on w/ Tab order and this definitely seems to smooth things out. 

Troubleshooting

When in doubt, delete the control.

"Something" strange has happened.  I've had it happen a few times.  The only 100% successful answer I have is to delete the control and recreate.  I've solved this a number of times w/ icons or fields that simply wouldn't work properly.  You could create an identically functioning control and copy all values and one works but the other doesn't.  I don't know what to tell you other than to not waste time on something like this.  It is just a part of the current environment.

If you have a control that isn't showing focus (e.g. no change in border or color) then the most likely issue is that it isn't getting focus.  The issue is not that you have some wonky value on your "OnFocus" color schema.  The control is screwed up.  Delete and recreate first before you waste more time.

Don't fuss over TabIndex early

I now have the habit of telling testers to ignore tab/alt-tab issues until the last phase testing.  Product Owners change their minds a lot and it is simpler to avoid the extra work until this is needed.  Once the forms are settled, then dig into this.  Easy enough to fix or delete/replace depending on how screwed up a control got due to constant changes.

The <Enter> key "doesn't work"

Ok, this isn't 100% true.  If you have a normally responsive control selected (e.g. a button) and hit the <Enter> key (or the spacebar), then the control's "OnSelect" event fires.  Same for icons.  HOWEVER, for fields (e.g. edit form field), the OnSelect event fires if the control is clicked into (e.g. mouse).  IT DOES NOT FIRE WHEN YOU HIT <ENTER>.  

Where this screws people up is you might be used to a "default behavior" setting that ties a field to a control (e.g. press Enter inside a Search field and the "Search" icon next to it acts like you pressed it).  THAT DOES NOT EXIST WITHIN POWERAPPS CURRENTLY.  No dice.  Won't work.  Take a candy break if you need to.  You just need to get over this (near term).

This and other "quirks" of PowerApps are primarily due to the #1 focus for PowerApps being mobile.  Since there is not generally an <Enter> key style behavior on mobile (users are expected to touch a button/control), that was overlooked and/or de-prioritized since it primarily impacts desktop users.

Containers can throw things off (2023/2/1)

The new Container controls seem to take a Tab space themselves even if they have no actual TabIndex property.  So be aware that if you use containers, then one of the Tab presses will enter/exit the container and THEN go to the next control in your list.

So if I have an item w/ a TabIndex of 1 in one Container and another w/ 2 in another Container, then there will be 2 Tab presses to get there.  First to go to the next Container, next to go to the next control inside the Container.  

It almost makes sense, but...no.