voiceOver.navigateToWebContent has no effect in the example test

[dmurvihill]

When running the Real World Example on Sequoia 15.7.3, the test misses the "skip to content" link and gets bogged down in the top nav (video attached). Even with a three minute timeout, there is not enough time to reach the Guidepup heading.

guidepup-no-skip-to-content.mp4

[cmorten]

Hi @dmurvihill

Which versions of @guidepup/guidepup and @guidepup/playwright do you have installed in your lockfile?

This looks like auto web navigation not being disabled so good to know if on the latest versions.

[dmurvihill]

        "@guidepup/guidepup": "^0.28.0",
        "@guidepup/playwright": "^0.15.0",

[cmorten]

Please could you try out the latest versions? (Unless confirm already on them in lockfile, possible based on your semver ranges)

[dmurvihill]

Updated @guidepup/playwright to 0.17; timing is different but it still misses the "Skip to Web Content" link.

@guidepup/guidepup is on latest.

guidepup-playwright-issue-43-on-v17.mp4

[cmorten]

Ok, main issue appears to be that navigateToWebContent() is either not working or not running at all (/completely)

In the latest version it should open an item menu, search for web content, and take you to the start of the web content.

That isn’t happening at all so need to figure out why - the large number of beeps at the start might indicate VO not executing commands, but unsure.

The navigation through the header is then auto navigation, a VO option that is on by default (can be changed by a user in VoiceOver Utility app manually). There is some logic to interrupt it in navigateToWebContent() but unclear if it’s not working, or never getting that far…

I don’t have a device running Sequoia and this doesn’t reproduce in GitHub CI that I’ve seen recently, but it has on previous versions so is semi known issue. Perhaps have a race condition on startup?

[dmurvihill]

Happy to do additional diagnostics if it would be helpful.

[cmorten]

As a starter for 10, would it be possible for you to manually perform the steps that navigateToWebContent() performs (separate from a test run) to see if encounter any issues?

REF: https://github.com/guidepup/guidepup-playwright/blob/main/src/voiceOverTest.ts#L93

i.e.

1. Open Safari and navigate to the page
2. Start VoiceOver manually Cmd-F5
3. Bring Safari to front
4. Key Ctrl (to cancel any auto-navigation)
5. Key Ctrl-Option-I (to open the item chooser)
6. Type web content
7. Key Enter (to select the browser web content)
8. Key Ctrl-Option-Shift-Down Arrow (to interact with the web content)
9. Key Ctrl-Option-Shift-Home or Ctrl-Option-Shift-Fn-Left Arrow on a laptop (to shift to the first content)
10. Key Ctrl (to cancel any auto-navigation)

It would be grand to understand if there are any flaws in the logic for deterministically landing on the first item of the page.

If happy to clone this repo, run the examples, and help experiment with the navigateToWebContent() implementation to find something stable for your setup also much appreciated. Could be need more liberal use of await voiceOverPlaywright.perform({ keyCode: MacOSKeyCodes.Control }); as maybe browser auto-navigation is kicking off after running that command or similar?

[dmurvihill]

It looks like moveToBeginningOfText (VO + Shift + Home) is going to the top of the window instead of the beginning of the text.

guidepup-playwright-issue-43-stepthru.mp4