(In reply to Joanmarie Diggs from comment #38) > (In reply to :Gijs (he/him) from comment #36) > > (In reply to Joanmarie Diggs from comment #35) > > > So I just landed a change in Orca master which uses accessibility API (AtkComponent) to look for a banner overlay > > > > Look for it how? > > https://gitlab.gnome.org/GNOME/orca/blob/e2cb51b/src/orca/eventsynthesizer.py#L333 > > Alex says this doesn't work for him (reason why TBD). But for me it's working quite well. > > Your implementation of atk_component_get_accessible_at_point() is apparently diving down finding the deepest tree node at the specified coordinates. So I'm using that to look for an accessible object which is at the same y coordinate as the object to be shown but occupies the width of the document. I'm sure there will be edge cases, but at least it's a start.... OK. I'm having trouble parsing: > ` if not (left and right and left == right != document):` But there's a few assumptions/decisions here that I think we'd be reluctant to make in Firefox proper and/or use whenever we're scrolling as a result of user focus / findbar / AT scrolling: 1. it only cares about the scrollable container being the document, not other scrollable things 2. it probably (unsure how atk_component_get_accessible_at_point is implemented) gets the element with the highest z-index and assumes that that obscures things, irrespective of whether it is/isn't transparent, whether it takes/ignores mouse events, whether it's in the process of animating away (or animating further in), ... 3. it only measures that innermost object that it happens to stumble upon, so it's not clear why it would get the right dimensions to use to adjust the scroll position - perhaps it's the containing object that is obscuring things, or the thing on top of that, or ... 4. it scrolls twice, which is likely to appear jumpy on slower machines / if page style changes in response to the scrolling 5. it hardcodes 25 (something - px?) on top of the height of the banner - unclear what that's about... 6. it only affects scrolling upwards 7. it won't work if the scroll operation that adjusts for the position of the banner itself ends up changing layout (ie if the page CSS/JS responds to the scroll - which happens for me, the banner size on google.com search results is dependent on the vertical scroll position)
Bug 1572680 Comment 39 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Joanmarie Diggs from comment #38) > (In reply to :Gijs (he/him) from comment #36) > > (In reply to Joanmarie Diggs from comment #35) > > > So I just landed a change in Orca master which uses accessibility API (AtkComponent) to look for a banner overlay > > > > Look for it how? > > https://gitlab.gnome.org/GNOME/orca/blob/e2cb51b/src/orca/eventsynthesizer.py#L333 > > Alex says this doesn't work for him (reason why TBD). But for me it's working quite well. > > Your implementation of atk_component_get_accessible_at_point() is apparently diving down finding the deepest tree node at the specified coordinates. So I'm using that to look for an accessible object which is at the same y coordinate as the object to be shown but occupies the width of the document. I'm sure there will be edge cases, but at least it's a start.... OK. I'm having trouble parsing: > ` if not (left and right and left == right != document):` But there's a few assumptions/decisions here that I think we'd be reluctant to make in Firefox proper and/or use whenever we're scrolling as a result of user focus / findbar / AT scrolling: 1. it only cares about the scrollable container being the document, not other scrollable things 2. it probably (unsure how atk_component_get_accessible_at_point is implemented) gets the element with the highest z-index and assumes that that obscures things, irrespective of whether it is/isn't transparent, whether it takes/ignores mouse events, whether it's in the process of animating away (or animating further in), ... 3. it only measures that innermost object that it happens to stumble upon, so it's not clear why it would get the right dimensions to use to adjust the scroll position - perhaps it's the containing object that is obscuring things, or the parent of that element, or ... 4. it scrolls twice, which is likely to appear jumpy on slower machines / if page style changes in response to the scrolling 5. it hardcodes 25 (something - px?) on top of the height of the banner - unclear what that's about... 6. it only affects scrolling upwards 7. it won't work if the scroll operation that adjusts for the position of the banner itself ends up changing layout (ie if the page CSS/JS responds to the scroll - which happens for me, the banner size on google.com search results is dependent on the vertical scroll position)