1180581 - crash in mozilla::a11y::HyperTextAccessible::RelationByType(mozilla::a11y::RelationType)

Status: RESOLVED DUPLICATE of bug 1179483

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

This bug was filed from the Socorro interface and is 
report bp-3d89d3ff-e018-4a14-a7ef-eaa302150706.
=============================================================

I am still getting crashes in this area, this particular one when opening the web page:
http://www.drwindows.de/windows-10-desktop/85128-updates-ausblenden.html

Or when performing a Google search for "Windows 10 updates ausblenden" and selecting this particular search result. Latest nightly crashes reliably for me, suggesting that mContent is once again not valid, and no null check is performed.

Alex, Fredw, any leads on why this is happening so frequently now?

Comment 2

[Frédéric Wang (:fredw)]

(In reply to Marco Zehe (:MarcoZ) from comment #0)
> Alex, Fredw, any leads on why this is happening so frequently now?

As I read the code, this is going to happen for any object using the generic "HyperText" accessible and that does not have actual DOM content, for which parent/child relations is requested.

Comment 3

[Marco Zehe (:MarcoZ)]

(In reply to Frédéric Wang (:fredw) from comment #2)
> As I read the code, this is going to happen for any object using the generic
> "HyperText" accessible and that does not have actual DOM content, for which
> parent/child relations is requested.
So, is the correct solution indeed to check whether the object has its own DOM content, and if not, bail out? Or is the fact that some objects don't have their own DOM content actually an error?

Comment 4

[Frédéric Wang (:fredw)]

(In reply to Marco Zehe (:MarcoZ) from comment #3)
> So, is the correct solution indeed to check whether the object has its own
> DOM content, and if not, bail out? Or is the fact that some objects don't
> have their own DOM content actually an error?

My guess is that it is correct to check whether it has a DOM content (since in this particular case we are testing MathML). But Alex's comment on the original bug seemed to say that it is actually not necessary so perhaps it is an error that an object without DOM content lands here. I don't know enough the accessible code, but IIUC we sometimes use these kinds of "fake accessibles".