Closed Bug 1784907 Opened 2 years ago Closed 2 years ago

When opening a link in a new tab, visited State changes for links not reflected in the JAWS virtual buffer most times

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Version:
Firefox 105
Platform:
x86_64
Windows 10
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox105 --- affected

People

(Reporter: MarcoZ, Unassigned)

References

Details

(Whiteboard: [ctw-m3])

Prerequisites:

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

Steps:

  1. With JAWS running, launch Firefox.
  2. Go to https://www.mozilla.org.
  3. Find an unvisited link, for example the "Learn more about us" or any other link on the start page that you haven't previously visited, and arrow to it using the JAWS virtual cursor.
  4. Press CTRL+Tab to open the link in a new tab. I have set my Firefox to open new tabs in the foreground, but any setting should do.
  5. If the new tab opened in the foreground, press CTRL+W or CTRL+Shift+Tab to either close and return to, or just return to the previous tab from which you opened the link.
    • Expected: The now visited link, indicated visually, should also be visited for the screen reader.
    • Actual: It is in most cases still marked as unvisited.
  6. Press Insert+Escape to refresh the JAWS virtual buffer.
    • Result: Now, the visited state of the link is reflected in the virtual buffer as well.

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

  1. The visited 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.

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. I can confirm that very rarely, the visited state updates. I don't know if it is due to some other event that triggers a refresh of the virtual buffer, or if JAWS really updates the state on this element only. With the cache enabled, updates happen so fast that it is rarely ever noticeable any more. Which is a good thing, mind you. :-)

Thanks for confirming.

I just double checked that we update the state cache before firing the event to Windows and we do.

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.

Whiteboard: [ctw-m3]
Severity: -- → S3

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

Depends on: 1786240

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

Flags: needinfo?(marco.zehe)

Yes, this works now. Thanks!

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(marco.zehe)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.