[Webkit-unassigned] [Bug 56737] New: [GTK] [Stable] AtkHypertext exposes wrong offsets for links placed inside <span> nodes

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=56737

           Summary: [GTK] [Stable] AtkHypertext exposes wrong offsets for
                    links placed inside <span> nodes
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: Gtk
          Severity: Normal
          Priority: P2
         Component: Accessibility
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: msanchez at igalia.com
                CC: joanmarie.diggs at gmail.com
            Blocks: 25531


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...

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.