Bug 56737 – [GTK] [Stable] AtkHypertext exposes wrong offsets for links placed inside <span> nodes

• Status: RESOLVED
• Resolution: FIXED
• Component: Accessibility

[Mario Sanchez Prada]

When showing ORCA's help in last version of Yelp, the offsets of hyperlinks are generally exposed wrong, since they always are reported to start in offset 0, no matter where in paragraphs they are. Check links in orca/help/C/introduction.page with Yelp, for instance, to see it yourself.

It seems the problem comes from the fact that Yelp always represents links (<link> tag in Yelp's markup, different from HTML's <link>) in a paragraph in HTML as follows:

  <p>Some text before the link <span><a href='...'>text for the link</a></span> and some text after the link</p>

The problems seems to come because current implementations of atk_hyperlink_get_start_index() and atk_hyperlink_get_end_index() are wrong, as they do not check the offset position of a link inside its immediate parent, no matter that parent is exposed to AT's (e.g. paragraphs or list items) or not (such as the <span> nodes).

So, in the example above, as the link is actually at the offset 0 for its inmediate parent (<span>) it will always return that wrong value, when it should be returning the offset inside the first unignored parent (<p>) instead.

Setting the "[GTK] [Stable]" prefix, as this is a very severe issue that should be shipped ideally with the next 1.4.0 stable release of wkgtk. 

Uploading a patch for it along with the updated tests soon...

[Mario Sanchez Prada]

Created attachment 86313 [details]
Patch proposal + Unit test

Attaching patch proposal + updated an already present unit test to check hypertext/hyperlink stuff

[Martin Robinson]

Comment on attachment 86313 [details]
Patch proposal + Unit test

Looks sane to me!

[Mario Sanchez Prada]

Committed r81587: <http://trac.webkit.org/changeset/81587>