1846186 - [meta] Bounds and hittesting incorrect for multiple elements on db.msin.jp

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[kil]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/112.0

Steps to reproduce:

This site has a lot of "images + links" block elements (NSFW)
https://db.msin.jp/jp.page/createdate?date=2023-07-12

The structure of each block is:
Images
Date Links
Category links
Title link
Actor link

Actual results:

In the current and latest nightly version(117.0a1 2023-07-30)
When first opened (without caching), the accName and accValue values for the title link and actor link are usually null, with a few occasional non-null values.
However, the accName and accValue values of the block elements at the bottom of the page are always null.
If the page is refreshed (after a full load), the above problem disappears and the accName and accValue values become normal.

If you repeat the test page, please clear the cache, or change the date in the url.

Comment 1

[kil]

Is this problem hard to solve? I've been checking daily to see how it's progressing, but I'm disappointed every time.

Comment 2

[Morgan Reschenberg [:morgan]]

(In reply to kil from comment #1)

Is this problem hard to solve? I've been checking daily to see how it's progressing, but I'm disappointed every time.

Hi there,

The first step in solving bugs is often to reduce them to a simple test case -- ie. identify a subset of the page's HTML / CSS / JS that causes the issue and create a test page that has only that code on it. This means the issue reproduces consistently and without other potentially distracting/red-herring code. With this test case, we can debug the accessibility engine to identify in which portion of our caching infrastructure this issue occurs.

I have not yet been able to distill this issue, but I am investigating. If you're able to distill it please post the test case here as a comment. Thank you!

Comment 3

[kil]

(In reply to Morgan Reschenberg [:morgan] from comment #2)

(In reply to kil from comment #1)

Is this problem hard to solve? I've been checking daily to see how it's progressing, but I'm disappointed every time.

Hi there,

The first step in solving bugs is often to reduce them to a simple test case -- ie. identify a subset of the page's HTML / CSS / JS that causes the issue and create a test page that has only that code on it. This means the issue reproduces consistently and without other potentially distracting/red-herring code. With this test case, we can debug the accessibility engine to identify in which portion of our caching infrastructure this issue occurs.

I have not yet been able to distill this issue, but I am investigating. If you're able to distill it please post the test case here as a comment. Thank you!

Thank you for your reply. Sorry I can't be of more help. This problem is not like 1837414 which can be reproduced 100%, it has randomness.
I tested this page using AutoHotkey calling UIAutomation and it was a disaster, again not getting the name/value and huge latency and lag.

Comment 4

[Morgan Reschenberg [:morgan]]

There seem to be a few issues on this page, which may or may not be related

1. There is a sidebar on the lefthand side of the page which contains several headings and nested divs with text content. On my screen, this sidebar overflows the viewport in the Y direction, so you have to scroll to see the rest of its content. All information in the sidebar hittests accurately on initial page load, including the content outside of the viewport (in fact, when you try to hittest a container that is partially but not completely within the viewport, VO appropriately scrolls the entire container on screen, which makes me think this information is correctly cached even without triggering a cache push via scrolling. this is good :) ). When you scroll the page "down" such that the sidebar content is offscreen, the side bar jumps to make itself visible again. This is accomplished by manipulating the padding property, not via any position info -- so I think we need to add padding to the props we monitor style changes on.

2. Information in the "movie details" element is not hittestable on initial page load -- specifically, this is a problem for "move create" and "movie mfr" elements. If I use VO with keyboard to navigate to these items, the visual cursor is ~30 pixels above where the actual text appears on screen (though its height and width appear correct). When I scroll the page and try to locate these items with VO + keyboard, the visual cursor appears in the same spot, offset from the top of the page. Again, seems like a bounds issue rather than a hittesting/viewport one.

3. Some elements that are not in the viewport on initial page load are not hittestable. This does not appear to be true for the images / play button images. It does seem to be true for the text in the "movie details" section (including "movie title" and "movie artist" which previously worked). I wonder if they're doing some scrolling hack here with padding, too, but I couldn't find it in the js like I could for the sidebar. Interestingly, if I use VO to nav to these items with the keyboard, the "movie create" and "movie mfr" elements are still misplaced, but the "movie title" and "movie artist" ones appear correctly bound by the visual cursor. Also, once I've navigated to them with the keyboard, they're hittestable with the mouse (even if I move the visual cursor elsewhere and then revisit the elements with the mouse)...

Comment 5

[kil]

Sorry, I forgot an important parameter, the DPI of my Window system is set to 200% .

Comment 6

[James Teh [:Jamie]]

Morgan, any idea whether (any of) this is fixed by bug 1853468?

Comment 7

[kil]

In nightly, the accName and accValue values for the title link and actor link become normal, but the accValue value for the image element remains empty.

Comment 8

[Morgan Reschenberg [:morgan]]

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

Morgan, any idea whether (any of) this is fixed by bug 1853468?

I see the same thing as :kil -- the bounds of all the text / links / sidebar content is fixed, but the bounds of the linked images are still incorrect.
When I nav to them via the VO cursor, I get a box that tightly bounds the image's width, but is anchored to the bottom of the image and only ascends maybe ? 40 px instead of the full ~400px height.

Comment 9

[kil]

After the 1864511 fix, on the db.msin.jp page, 121 still has one difference from 112.
Below the image element is an "...配信先へ" link that contains an icon. 112 sees the icon as part of the link, and thus the accName/accValue values are normal. 121 doesn't seem to see the icon as a link, and thus the accName/accValue is null.

Comment 10

[James Teh [:Jamie]]

If I route the mouse to the "...配信先へ" link, Firefox correctly hit tests the link. But maybe the bounds are wrong.

Morgan, do you see correct bounds for these links?

Comment 11

[Morgan Reschenberg [:morgan]]

I see the right bounds for the link text, I think the icon that isn't being included is a pseudoclass SVG. It doesn't show up in the accessibility tree.
The link is something like:
<a href="...">text ::after</a>
where the ::after class includes a background-image: svg(); that shows an "external link" icon (arrow pointing out of a box).

I think the issue :kil is describing is that when you hittest the icon you don't get the link accessible, because the link bounds don't include it.
I'm not sure what to do here, I'd need to figure out if GetFramesForArea supports getting pseudoclass frames (do they have frames?) and if we could find a way to tie them back to their nearest acc/element. I think we're probably running into trouble here

Comment 12

[James Teh [:Jamie]]

(In reply to Morgan Reschenberg [:morgan] from comment #11)

I see the right bounds for the link text, I think the icon that isn't being included is a pseudoclass SVG. It doesn't show up in the accessibility tree.
...
I think the issue :kil is describing is that when you hittest the icon you don't get the link accessible, because the link bounds don't include it.

If it doesn't show up in the a11y tree, should we really be including it at all? I don't even really understand why the LocalAccessible hit testing code would include it. That seems like a happy accident bug rather than intentional behaviour.

I'm guessing this doesn't work in Chrome or Safari either? If not, I think this part is a wontfix, as the previous behaviour is technically wrong, albeit beneficial for this specific use case.

Comment 13

[kil]

In Chrome, when the mouse moves over this icon, you can get the acc value of the link, just like V112.

Comment 14

[James Teh [:Jamie]]

Intriguing. Morgan, I wonder if the bounds of the link include the pseudo-element in Chrome?

Comment 15

[Morgan Reschenberg [:morgan]]

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

Intriguing. Morgan, I wonder if the bounds of the link include the pseudo-element in Chrome?

Yes, they do.

Comment 16

[kil]

On some pages, zooming causes acc to fail.
For example, on https://konachan.com/post (NSFW), zoomed to 170% (remember to refresh after zooming), the acc values for the links and images at the bottom are not available.
This really made me despair, after a long wait and anticipation.
I compared the acc-AccessibleObjectFromPoint() performance of v121 and v112, and there's no difference in time consumption between the two. I have not found any advantage of the new acc so far. Is there any way to restore the 112 acc in 121?

Comment 17

[James Teh [:Jamie]]

(In reply to kil from comment #16)

I compared the acc-AccessibleObjectFromPoint() performance of v121 and v112, and there's no difference in time consumption between the two. I have not found any advantage of the new acc so far.

There might not be any advantages for your specific use case, but there are definitely advantages for many others, as well as extremely severe stability and reliability bugs that we couldn't fix with the old architecture.

Is there any way to restore the 112 acc in 121?

Unfortunately not. Maintaining two entirely different architectures simply isn't feasible.

We will investigate the additional bugs you've reported. Thanks for taking the time to do so.

Comment 18

[kil]

Attachment: Discuz Forums

https://discuz.dismall.com/forum-plugin-1.html

Comment 19

[Morgan Reschenberg [:morgan]]

I cannot reproduce the issue shown in the gif for discuz (mouse moving horizontally over a single discussion board title in the middle of the page, shown in a tooltip are acc titles for the hittesting location of the mouse, instead of reading the hovered discussion title, titles from the boards above and below are read) but I can repro the zoom issue, I'll file a bug.

Comment 20

[kil]

Yes, the image uses 121 beta5, I didn't reproduce it at 120.0.1.

Comment 21

[kil]

In V120.0.1, the accName in the address bar is the url and the accValue is empty.
In V112 and Chromium, accValue is url and accName is the "url or search" prompt character.

Comment 22

[James Teh [:Jamie]]

(In reply to kil from comment #21)

In V120.0.1, the accName in the address bar is the url and the accValue is empty.

I can't reproduce this in 122 Nightly. I haven't tested with 120 yet, but regardless, this appears to be working in 122.

Note that the URL bar is handled very separately from hit testing in web documents, so this is not related to the new architecture and is a separate issue if it still exists.

Comment 23

[kil]

Attachment: Nightly-122

I have been able to reproduce it in Nightly-122.
About the Discuz Forums error, it's because I wrote xy as xx when I wrote the test code, I'm very sorry. But the Discuz Forums error does exist in 121 beta5, but it's not that dramatic. I didn't reproduce it in Nightly-122 and I'm glad it's fixed or gone.