Bug 73433

Summary: [Gtk][WK2] atk_text_get_text_at_offset() fails to provide the correct line for text which is wrapped
Product: WebKit Reporter: Joanmarie Diggs <jdiggs>
Component: AccessibilityAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: mario, mrobinson
Priority: P2 Keywords: Gtk
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 114872    
Bug Blocks: 72588    

Description Joanmarie Diggs 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.