1466551 - EVENT_OBJECT_LOCATIONCHANGE not fired for items in a html list box if it scrolls.

Status: VERIFIED WORKSFORME

(Core :: Disability Access APIs, defect, P3)

Description

[Mike HIll]

If you have a standard HTML list box element with a fixed size so the number of list elements doesn't fit in the box, then once the contents have scrolled, the location of each list item reported through accLocation is incorrect. The location reported is not updated after the list box scrolls.

This is an issue for screen readers/magnifiers which are attempting to visually track the highlighted item in a list box as the user cursors up and down.

 
<p>scrollable List: <select id="test2" size="5">
<option value="volvo">1 Volvo</option>
<option value="saab">2 Saab</option>
<option value="mercedes">3 Mercedes</option>
<option value="ford">4 Ford</option>
<option value="audi">5 Audi</option>
<option value="volvo">6 Volvo</option>
<option value="saab">7 Saab</option>
<option value="mercedes">8 Mercedes</option>
<option value="ford">9 Ford</option>
<option value="audi">10 Audi</option>
</select></p>

Comment 1

[Mike HIll]

Updated bug description after further diagnosis.

Firefox is not firing an EVENT_OBJECT_LOCATIONCHANGE for the items in a list box, when the box scrolls. This was causing Supernova to use out-of-date locations from it's cache for it's visual highlighting.

Comment 2

[Marco Zehe (:MarcoZ)]

Mike, can you try this again in Nightly (Firefox 62), please? There were some changes recently to the bounds and location code, and this might have been fixed alongside. Just to be sure we're not trying to diagnose an already fixed bug.

Comment 3

[James Teh [:Jamie]]

Mike, are you able to give a general idea of cases where you require location change events? The problem with these events is that in theory, when a page scrolls, we'd need to fire a location change event on almost *every* object (since almost every object changes its location). That could be a very large number of objects and would almost certainly result in performance problems for both Firefox and AT every time the page scrolls (which could happen quite a lot).

Comment 4

[Mike HIll]

I have just tried the nightly build (06/04/2018) - same result.

I use location for visual highlighting for magnifier users, the scenario is that the user is using the keyboard or mouse to interface with a list box. They expect the magnifier to track the focused item's location. 

For performance reasons, I have general system in Supernova that caches as much information as possible and use the Events to determine if the cache is invalid. I assume that the location of an object wont have changed unless I get a location change event. If the object is possibly deleted or changed due to a parent's reorder, insert or delete event then I will also invalidate my location cache. This strategy works well in Chrome and Internet Explorer :-) 

I understand the problem with sending too many events, however you shouldn't need to do this. As I understand the Microsoft documentation for EVENT_OBJECT_LOCATIONCHANGE "This event is generated in response to a change in the top-level object within the object hierarchy; it is not generated for any children that the object might have.", you only need to send this event for the top most object that has moved, so you should never need to fire it for every object - just fire it for the top scroll-able container object and that will tell clients that all the children may have changed location. So if a web page scrolls, just fire this event on the document object. If a list box scrolls, fire it on the list box. When I get a location change event, I assume that the object and all it's children may have moved. I don't think it will hurt to fire it for an object if that object hasn't moved, but just it's children have.

Comment 5

[Mike HIll]

The other thing you could do to avoid sending lots of location change events is to send EVENT_SYSTEM_SCROLLINGEND to the parent object. This indicates that all the objects content's have scrolled and therefore have new locations.

Comment 6

[alexander :surkov (:asurkov)]

I think it is reasonable if the location change event was fired on the object's location change within its parent (bug 1469779), and agreed, it makes sense to fire scrollingend event for scrolling (this one).

Comment 7

[James Teh [:Jamie]]

(In reply to Mike HIll from comment #5)

The other thing you could do to avoid sending lots of location change events
is to send EVENT_SYSTEM_SCROLLINGEND to the parent object.

After bug 1611060 (available for testing in Firefox Nightly), we now fire EVENT_SYSTEM_SCROLLINGEND when scrolling finishes in any scrollable container. I just tested this with your test case in comment 0 and it fires on the list. Mike, would you be able to test with Firefox Nightly and confirm whether this works for you?

Comment 8

[Mike HIll]

I have tested with Firefox Nightly (2020-02-26) and can confirm that it's working. This fixes the issue with Supernova.

Comment 9

[Marco Zehe (:MarcoZ)]

Thank you, Mike! Closing as WORKSFORME. Fixed by bug 1611060.

Comment 10

[Marco Zehe (:MarcoZ)]

Verified via comment #8.