73433 2011-11-30 04:59:19 -0800 [Gtk][WK2] atk_text_get_text_at_offset() fails to provide the correct line for text which is wrapped 2013-09-11 04:05:30 -0700 1 1 1 Unclassified WebKit Accessibility 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED Gtk P2 Normal --- 114872 72588 0 jdiggs webkit-unassigned mario mrobinson oldest_to_newest 511644 0 117169 jdiggs 2011-11-30 04:59:19 -0800 Created attachment 117169 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. 872914 1 mario 2013-04-10 09:56:43 -0700 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. 872928 2 mrobinson 2013-04-10 10:20:22 -0700 (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. 873645 3 mario 2013-04-11 02:36:07 -0700 (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. 883885 4 mario 2013-05-02 12:22:00 -0700 (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 908943 5 mario 2013-07-16 10:13:13 -0700 (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 927716 6 mario 2013-09-11 04:05:30 -0700 This has been fixed along with patch for bug 114872, by getting rid of the pango/gail stuff.