Prerequisites:

• JAWS 2022
• Firefox Nightly with the Accessibility.Cache.enabled preference set to TRUE.

Steps:

1. With JAWS running, start Firefox.
2. Go to https://www.mozilla.org.
3. Focus the "Who We are" sub menu link and press Enter.
   • Result: The menu opens, the new items are available in the virtual buffer immediately. The Who We Are menu item now has the Expanded state.
4. Arrow down to the Close Who We Are Menu button and press Enter or Space.
   • Expected: Menu closes, which also gets reflected in the virtual buffer, and the Who We Are menu item appears as collapsed again.
   • Actual: Focus gets thrown to the top of the document. Visually, the menu closes. But when inspecting the virtual buffer, the expanded Who We Are item and the expanded sub menu are still there.
5. Press Insert+Escape to refresh the virtual buffer in JAWS.
   • Result: Now, the menu is closed, and the Who We Are item has its collapsed state again.

So, while expanding gets reflected immediately, collapsing does not.

I was able to reproduce this intermittently. I don't really understand why this happens:

1. The expanded state in the cache is actually updated using the same call that fires the event. So, if this were a Firefox caching bug, pressing JAWSKey+escape would not update the state in the buffer.
2. This doesn't happen with NVDA.

Have you seen this without the cache? I realise JAWS isn't fun to use without the cache, so I totally understand if you don't know, but thought I'd ask. It did seem to behave more consistently (albeit slower) without the cache here, but I only tested briefly. That said, I also saw this work a few times with the cache enabled.

Regardless, I'll probably need to ask Vispero for help with this.

I don't see this without the cache, that's why I reported it. Having said that, I can confirm that very rarely, it does update the state for me, too. If this is because something else triggers a buffer refresh in JAWS at the same time, I don't know. But with the cache enabled, it is very rare.

Tentatively assigning this to ctw-m3, but whether we can fix this in that timeline depends on whether I can figure out what's going on and/or get help from Vispero.

I tested this with my fix for bug 1786240 and this problem seems to be addressed as well.

Marco, would you mind testing this with latest Nightly? As per comment 4, I did test this myself, but I wasn't ever able to reproduce this as reliably as you could.

Yes, this works now as expected.