1452008 - Negative width for off-screen control (AKA some off-screen radio buttons not visible in NVDA browse mode)

Status: RESOLVED FIXED

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

Description

[James Teh [:Jamie]]

STR (with the NVDA screen reader):
1. Open this URL:
data:text/html,<input type="radio" id="radio" style="left: -671091em; position: absolute;"><label for="radio">Label</label>
2. Press control+home to read the top line of the document.
Expected: NVDA should say: "radio button not checked"
Actual: NVDA says: "Label"

The radio button doesn't get rendered into the buffer at all. It gets treated as invisible because the reported width is negative (-34). If you change this to instead use "left: -671090em", the reported width is 32. This is suggestive of an overflow somewhere.

This does not occur in Firefox 56.

This was prompted by a real world use case. ANZ internet banking (in Australia) uses this code:
<input value="ONLINE" id="onlineOnlyRadio_0" name="contactPrefRadio_0" style="left:-999999em;position:absolute;" checked="" type="radio">
As a result of this, I can't use some functions of my internet banking. :( I guess they must draw the actual visual control in some other way and they just have the radio input for keyboard/a11y. Weird, but it's in the wild. Pretty sure I've seen a similar failure elsewhere too.

Comment 1

[James Teh [:Jamie]]

35:44.08 INFO: Last good revision: 2e16779c96ccde81cc863a984d132e3132e5f7d6
35:44.08 INFO: First bad revision: 19d0b0f36ccea9d991eb1891e6cb88b4e82f5d92
35:44.08 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2e16779c96ccde81cc863a984d132e3132e5f7d6&tochange=19d0b0f36ccea9d991eb1891e6cb88b4e82f5d92

This suggests the regression was introduced by bug 1437492.

Comment 2

[James Teh [:Jamie]]

Hi Bas. Bug 1437492 seems to have caused a regression in the width reported by accessibility for some off-screen controls. As noted in comment 0, this looks to me like an overflow somewhere. Are you able to shed any light on this? Thanks.

Comment 3

[Bas Schouten (:bas.schouten)]

(In reply to James Teh [:Jamie] from comment #2)
> Hi Bas. Bug 1437492 seems to have caused a regression in the width reported
> by accessibility for some off-screen controls. As noted in comment 0, this
> looks to me like an overflow somewhere. Are you able to shed any light on
> this? Thanks.

Hmm, I'm unsure how this could cause a change in -when- overflows happen, but that's a very interesting observation, I'll have to investigate further. I suppose the patch could cause -less- overflows to happen in some situations, but certainly not more.

Comment 4

[Bas Schouten (:bas.schouten)]

Is there a way I can test this in a clean firefox profile without the NVDA screenreader? Perhaps testing for the width of the element somehow? I'm not great with DOM or JS stuff but I'd imagine there's a line I can use for testing this :). I don't see any overflows happening inside the matrix class when I just load the page.

Comment 5

[Marco Zehe (:MarcoZ)]

Bas, I don't know where Jamie got the exact values for the width of the element, since for both em values, I get a clientWidth and an offsetWidth of 13, and a normal width value of 0, but nothing says 32 or 34, but I believe what Jamie was referring to is the bounds and width and height calculated by the accessibility engine.

For JS, I used

document.getElementById("radio").clientWidth, offsetWidth, and width respectively. You can also play around with the clientLeft, offsetLeft values.

I can definitely reproduce the bug as well, but on quick testing, didn't find a good way without NVDA to get a clue about the values.

Comment 6

[Bas Schouten (:bas.schouten)]

(In reply to Marco Zehe (:MarcoZ) from comment #5)
> Bas, I don't know where Jamie got the exact values for the width of the
> element, since for both em values, I get a clientWidth and an offsetWidth of
> 13, and a normal width value of 0, but nothing says 32 or 34, but I believe
> what Jamie was referring to is the bounds and width and height calculated by
> the accessibility engine.
> 
> For JS, I used
> 
> document.getElementById("radio").clientWidth, offsetWidth, and width
> respectively. You can also play around with the clientLeft, offsetLeft
> values.
> 
> I can definitely reproduce the bug as well, but on quick testing, didn't
> find a good way without NVDA to get a clue about the values.

Any idea how I might get to those values calculated by the accessibility engine (Obviously this is possible since Jamie did it :))? It'd be great if I were able to step through the calculation process.

Comment 7

[James Teh [:Jamie]]

Yes, I was referring to the width as returned by the accessibility engine. I can't seem to find a way to get this with JS; e10s makes this tricky. However, you can see the underlying problem by entering this in the web console:
document.querySelector("input").getBoundingClientRect().width
On my system, I get -13.599990844726562 for the test case in comment 0.

Comment 8

[James Teh [:Jamie]]

If it helps, the code accessibility uses to calculate the bounds is in mozilla::a11y::Accessible::Bounds:
https://searchfox.org/mozilla-central/source/accessible/generic/Accessible.cpp#668

Comment 9

[alexander :surkov (:asurkov)]

Bas, does Jamie's pointer help?

Comment 10

[James Teh [:Jamie]]

Update: I asked Bas about this on IRC:
"You should probably ask someone in graphics or layout, I'll doubt I get to this within the next month and a half."

Comment 11

[James Teh [:Jamie]]

Fixed, probably by bug 1695716, which also added a test.