Open Bug 1899658 Opened 5 months ago Updated 5 hours ago

Hittesting, Bounds incorrect for APZ + scrolled elements

Categories

(Core :: Disability Access APIs, defect)

defect

Tracking

()

People

(Reporter: morgan, Assigned: morgan)

References

(Blocks 1 open bug)

Details

STR:

  1. Load data:text/html,<BR><BR><BR><BR><BR><BR><button>hello</button><button>I am a button with a longer label
  2. APZ "in" such that elements are larger but still entirely visible within the viewport
  3. Set scroll position to 0 by scrolling to the top of the page
  4. Hittest elements with VO active, using the mouse

Expected / Actual:
VO's visual cursor tightly bounds each button, and VO correctly reads each role, button name

  1. Scroll the page such that the buttons are now in the upper left corner of the page (scroll position ~25%)
  2. Hittest elements with VO active, using the mouse cursor

Expected:
Same as above

Actual:
VO hittests the document

If you hittest the area the buttons were when the scroll position of the page was 0, you'll still find them there :)
I think we aren't correctly accounting for scroll position when APZ'd. We probably want to adjust this code in remote accessible or this code in local accessible.

This feels like a low-S2/high-S3. marking S3 for now

Severity: -- → S3
Assignee: nobody → mreschenberg
Duplicate of this bug: 1927237

Promoting to S2 because explore by touch is central in Android

Severity: S3 → S2
See Also: → 1916010

Chatted w/ botond about this on matrix -- looks like we can do a temp solution for android via this event which IPCs the APZ info from the GPU process to content and then to parent 🥲 the bug I See Also'd is about making a GPU -> Parent bridge, which is on APZ's to-do list

No longer duplicate of this bug: 1927237

I'm reopening the android version of this bug because it looks like we can fix the android case, and that is the real S2.

Severity: S2 → S3
You need to log in before you can comment on or make changes to this bug.