Closed Bug 1789235 Opened 2 years ago Closed 1 year ago

Scrolling start event not fired for anchor target if anchor jump occurs after focus event

Categories

(Core :: Disability Access APIs, defect)

defect

Tracking

()

VERIFIED FIXED
116 Branch
Tracking Status
firefox116 --- verified

People

(Reporter: Jamie, Assigned: nlapre)

References

(Blocks 1 open bug)

Details

(Keywords: papercut)

Attachments

(1 file)

STR (with NVDA):

  1. Open this test case:
    data:text/html,<p>a</p><p>b</p><p id="c">c</p><script>setTimeout(() => location.hash = '%23c', 3000);</script>
  2. Press control+home to ensure you're at the top of the document.
  3. Wait 3 seconds.
    • Expected: NVDA should report "c" as the document jumps to the "c" anchor.
    • Actual: Nothing happens.
  4. Press alt twice to bounce focus out of and back into the document.
    • Observe: NVDA reports "a" (for the line at the cursor) then "c" (as Gecko fires the scrolling start event it should have fired in step 3).

This scenario itself isn't a big problem; it's probably rare that a page would jump to an anchor itself like this. However, it is an easy way to reproduce a real world bug which is much harder to reproduce reliably. Sometimes (but not always), when you load a large page with a URL including an anchor target, Gecko doesn't fire a scrolling start event.

In bug 691734, the anchor jumping code was changed so that it only fires scrolling start events when it handles a focus event on the document. (This is the reason that step 4 "fixes" things above: because focus hits the document again.) This is still necessary: it's important that we fire the initial scrolling start event after the focus event. Otherwise, clients might miss it. However, it seems that we can sometimes get anchor jump notifications (nsAccessibilityService::NotifyOfAnchorJumpTo) after the document gets focus. (I'm not sure whether this is new or whether this bug has existed since bug 691734.) In this case, we should fire a scrolling start event as long as the document (or a descendant) still has focus.

It looks like I identified a similar problem in bug 1616164 three years ago. This fix would also cover that.

We should also see if we can fix bug 1615972 while we're dealing with this, since that will need tweaks to the same area of code.

Severity: -- → S3
See Also: → 1616164, 1615972
Keywords: papercut
Assignee: nobody → nlapre

This revision modifies NotifyOfAnchorJump in order to ensure that we fire a
scrolling start event for AT clients. Without this, clients might miss anchor
jump updates, since anchor jumps can arrive after getting focus. This revision
also adds a test to verify that the scrolling start event is now being sent.

Pushed by nlapre@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d7616232740d
Fire a scrolling start event for anchor jump if focus in doc, r=Jamie
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 116 Branch
Regressions: 1838782
No longer regressions: 1838782
Regressions: 1840253
Blocks: 1616164
See Also: 1616164
Flags: qe-verify+

Is this worth a backport to ESR115? It grafts cleanly.

Flags: needinfo?(nlapre)

It's a pretty annoying problem, so I think it's probably worthwhile, yes, particularly if it grafts cleanly.

Flags: needinfo?(nlapre)

Hm, upon further review and discussion with Jamie, I think uplifting this isn't worth the backport. It's not a security issue, also requires the following crash fix from Bug 1840253, and I don't think it's annoying enough to be worth it.

I've reproduced this issue using Nightly 106.0a1 (2022-09-05) following the STR from Comment 0 on Windows 10 x64 with NVDA enabled .
In the latest Firefox 116.0 under same configuration, without pressing control+home, NVDA reads out loud:
a b c
then it jumps to the "c" anchor
Pressing Alt twice at this point, NVDA reads out loud c.

Redoing all the STR from Comment 0, but pressing control+home and then pressing Alt twice, NVDA reads out loud a.
According to Comment 0, it should read out load:
a c

James, could you please share your thoughts here? Should I reopen this bug based on this?

Flags: needinfo?(jteh)

To clarify, are you doing and observing the following?

  1. Reload the test case.
  2. Immediately press control+home.
    • Observe: NVDA says "a"
  3. Wait 3 seconds.
    • Observe: After 3 seconds, NVDA says "c"

The 3 second period (from the time the test case loads to the time NVDA says "c") is important, as the test case scrolls to the "c" anchor after 3 seconds.

Flags: needinfo?(jteh) → needinfo?(epopescu)

(In reply to James Teh [:Jamie] from comment #9)

To clarify, are you doing and observing the following?

  1. Reload the test case.
  2. Immediately press control+home.
    • Observe: NVDA says "a"
  3. Wait 3 seconds.
    • Observe: After 3 seconds, NVDA says "c"

The 3 second period (from the time the test case loads to the time NVDA says "c") is important, as the test case scrolls to the "c" anchor after 3 seconds.

After loading the test case and pressing Ctrl+Home keys, NVDA reads:

a(and after 3 seconds)
c

However, NVDA doesn't read again a in this scenario:

4. Press alt twice to bounce focus out of and back into the document.
Observe: NVDA reports "a" (for the line at the cursor) then "c" (as Gecko fires the scrolling start event it should have fired in step 3).

It reads only c.

Flags: needinfo?(epopescu)

Aha. My apologies for the confusion. Step 4 only applies in the event that step 3 fails. If step 3 succeeds as expected, step 4 is invalid and should not be performed.

Thank you for letting me know.
Marking this as VERIFIED FIXED.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: