[Woo POS] TalkBack allows to switch from Cart to Totals layout without Checking Out

[staskus]

Describe the bug
A clear and concise description of what the bug is. Please be as descriptive as possible; issues lacking detail, or for any other reason than to report a bug, may be closed without action.

TalkBack allows to switch from Cart to Totals layout without Checking Out.

I tested on an emulator, it may be not reproducible on a device.

To Reproduce
Steps to reproduce the behavior:

1. Enable TalkBack
2. Open POS
3. Use arrows to go to right
4. Notice it's possible to go from Product List to Cart and then switch to Totals view

Video

TalkBack.can.switch.to.inactive.view.mov

Expected behavior
A clear and concise description of what you expected to happen.

Isolating the problem (mark completed items with an [x]):

• I have deactivated other plugins and confirmed this bug occurs when only WooCommerce plugin is active.
• This bug happens with a default WordPress theme active,
  or Storefront.
• I can reproduce this bug consistently using the steps above.

Mobile Environment
Please include:

• Device: Pixel Tablet Emulator
• Android version: API 34
• WooCommerce Android version:

WordPress Environment

``` Copy and paste the system status report from **WooCommerce > System Status** in WordPress admin. ```

[dangermattic]

Thanks for reporting! 👍

[kidinov]

I tried different approaches e.g.:

@Composable
private fun WooPosHomeScreen(
    state: WooPosHomeState,
    scrollState: ScrollState,
    productsWidthDp: Dp,
    cartWidthDp: Dp,
    totalsWidthDp: Dp,
    onHomeUIEvent: (WooPosHomeUIEvent) -> Unit,
) {
    val focusManager = LocalFocusManager.current

    LaunchedEffect(state.screenPositionState) {
        focusManager.clearFocus(force = true)
    }

    Box(
        modifier = Modifier
            .fillMaxSize()
            .background(WooPosTheme.colors.homeBackground)
    ) {
        Row(
            modifier = Modifier
                .horizontalScroll(scrollState, enabled = false)
                .fillMaxWidth()
                .focusGroup()
        ) {
            WooPosHomeScreenProducts(
                modifier = Modifier
                    .width(productsWidthDp)
                    .focusProperties {
                        canFocus = state.screenPositionState is WooPosHomeState.ScreenPositionState.Cart
                    }
            )
            WooPosHomeScreenCart(
                modifier = Modifier
                    .background(MaterialTheme.colors.surface)
                    .width(cartWidthDp)
                    .focusProperties {
                        canFocus = state.screenPositionState == WooPosHomeState.ScreenPositionState.Cart.Visible
                    }
            )
            WooPosHomeScreenTotals(
                modifier = Modifier
                    .width(totalsWidthDp)
                    .focusProperties {
                        canFocus = state.screenPositionState is WooPosHomeState.ScreenPositionState.Checkout
                    }
            )
        }

        WooPosHomeScreenToolbar(
            modifier = Modifier
                .padding(24.dp.toAdaptivePadding())
                .align(Alignment.BottomStart),
        )

        HandleProductsInfoDialog(state.productsInfoDialog, onHomeUIEvent)
    }
}

or with focusable(true/false)

But still, some internal elements of the subscreen could take the focus, which cause the scroll to another subscreen

Considering the impact, which is quite low, since a user needs to use a keyboard that is very rare. And nothing negative occurs—only another subscreen is visible, and the user just needs to click whatever they require to recover—I would propose closing this as high effort and very low impact.

@malinajirka @AnirudhBhat @samiuelson wdyt?

[AnirudhBhat]

Is this still reproducible from the latest trunk? I tried on both physical device and an emulator and couldn't reproduce it. Here's the video from my Pixel C tablet API 34 emulator.

talkback_pos.mp4

[kidinov]

@AnirudhBhat I think I could reproduce it using "keyboard" focus change or something like that, but in the usual way, not really

[AnirudhBhat]

I think I could reproduce it using "keyboard" focus change or something like that, but in the usual way, not really

Oh, I see. In that case, I think we could just close this issue as you suggested as this is something that would happen on an extremely rare condition and the time spending to fix this at this moment is not worth it.

[kidinov]

Ok lets close it!