Bug 73433 - [Gtk][WK2] atk_text_get_text_at_offset() fails to provide the correct line for text which is wrapped
Summary: [Gtk][WK2] atk_text_get_text_at_offset() fails to provide the correct line fo...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: Gtk
Depends on: 114872
Blocks: 72588
  Show dependency treegraph
 
Reported: 2011-11-30 04:59 PST by Joanmarie Diggs (irc: joanie)
Modified: 2013-09-11 04:05 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joanmarie Diggs (irc: joanie) 2011-11-30 04:59:19 PST
Created attachment 117169 [details]
test case

Created an attachment (id=117170)
test script

Steps to reproduce:

1. View the attached test case in WK2
2. Resize the window so that the text wraps
3. Enable caret browsing
4. Launch the attached test script in a terminal
5. Arrow Up and Down amongst the lines of text

Expected results: The test script would always print the correct text for the current line.

Actual results: The test script always prints the entire text for the current object, rather than just the current line.
Comment 1 Mario Sanchez Prada 2013-04-10 09:56:43 PDT
The problem, that only happens in WebKit2GTK+, seems to be related with this function:

  static PangoLayout* getPangoLayoutForAtk(AtkText* textObject)
  {
    AccessibilityObject* coreObject = core(textObject);

    Document* document = coreObject->document();
    if (!document)
        return 0;

    HostWindow* hostWindow = document->view()->hostWindow();
    if (!hostWindow)
        return 0;
    PlatformPageClient webView = hostWindow->platformPageClient();
    if (!webView)
        return 0;

    // Create a string with the layout as it appears on the screen
    PangoLayout* layout = gtk_widget_create_pango_layout(static_cast<GtkWidget*>(webView), textForObject(coreObject));
    return layout;
  }

As in WebKit2 this code is run from the WebProcess, webview there will be NULL, meaning that the PangoLayout returned here won't be associated to any widget as in the case of WebKit1, hence there's no way from GailUtil/Pango's perspective to realize whether the text is wrapped or not, and it will just see all the text in the paragraph as a whole.

So, I think that either we find a way to create a proper PangoLayout reflecting as well as possible the reality in the UI process or we just find a way to get the same result without using GailUtil + Pango at all, which is probably the best idea since we wanted to get rid of this APIs anyway, I think, and this might be a good reason to speed that up.
Comment 2 Martin Robinson 2013-04-10 10:20:22 PDT
(In reply to comment #1)

> So, I think that either we find a way to create a proper PangoLayout reflecting as well as possible the reality in the UI process or we just find a way to get the same result without using GailUtil + Pango at all, which is probably the best idea since we wanted to get rid of this APIs anyway, I think, and this might be a good reason to speed that up.

Getting rid of the pango dependency here is a step in the right direction, I think. The accessibility code shouldn't depend on a GtkWidget.
Comment 3 Mario Sanchez Prada 2013-04-11 02:36:07 PDT
(In reply to comment #2)
>[...]
> Getting rid of the pango dependency here is a step in the right direction,
> I think. The accessibility code shouldn't depend on a GtkWidget.

Yes, I already started making some local experiments to explore that approach. Hope I'll manage to get something useful soon.
Comment 4 Mario Sanchez Prada 2013-05-02 12:22:00 PDT
(In reply to comment #2)
> (In reply to comment #1)
> 
> > So, I think that either we find a way to create a proper PangoLayout reflecting as well as possible the reality in the UI process or we just find a way to get the same result without using GailUtil + Pango at all, which is probably the best idea since we wanted to get rid of this APIs anyway, I think, and this might be a good reason to speed that up.
> 
> Getting rid of the pango dependency here is a step in the right direction, I think. The accessibility code shouldn't depend on a GtkWidget.

Just realized I forgot to paste here the link to the metabug I filed to keep track of the efforts to remove pango dependency from a11y code:

https://bugs.webkit.org/show_bug.cgi?id=114867
Comment 5 Mario Sanchez Prada 2013-07-16 10:13:13 PDT
(In reply to comment #4)
> (In reply to comment #2)
> > (In reply to comment #1)
> > 
> > > So, I think that either we find a way to create a proper PangoLayout reflecting as well as possible the reality in the UI process or we just find a way to get the same result without using GailUtil + Pango at all, which is probably the best idea since we wanted to get rid of this APIs anyway, I think, and this might be a good reason to speed that up.
> > 
> > Getting rid of the pango dependency here is a step in the right direction, I think. The accessibility code shouldn't depend on a GtkWidget.
> 
> Just realized I forgot to paste here the link to the metabug I filed to keep track of the efforts to remove pango dependency from a11y code:
> 
> https://bugs.webkit.org/show_bug.cgi?id=114867

Just to mention we are getting closer to fixing this bug :)
https://bugs.webkit.org/show_bug.cgi?id=114872#c1
Comment 6 Mario Sanchez Prada 2013-09-11 04:05:30 PDT
This has been fixed along with patch for bug 114872, by getting rid of the pango/gail stuff.