[Webkit-unassigned] [Bug 25415] [GTK][ATK] Please implement support for get_text_at_offset

[bugzilla-daemon at webkit.org]

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





------- Comment #11 from joanmarie.diggs at gmail.com  2009-05-15 20:19 PDT -------
Created an attachment (id=30408)
 --> (https://bugs.webkit.org/attachment.cgi?id=30408&action=view)
test case

Hi Xan.

I did some thorough testing of your patch. Observations:

1. Given the variants present in implementations (e.g. Gedit/Gtk+ text objects,
OOo Writer, and Gecko), it looks like what you've done is most consistent with
Gedit/Gtk+ text objects. Yea! Thanks!! :-)

2. Given the text "This is another, silly test." (See attached test case.) I
compared what we get for getText{At,Before,After}Offset from Gedit and what we
now get from WebKit:

  * TEXT_BOUNDARY_CHAR is the same in both.

  * TEXT_BOUNDARY_WORD_{START,END} is essentially the same, however:

    - When we do a getTextAtOffset(i, TEXT_BOUNDARY_WORD_END) where
      i is an offset of a character in the first word, Gedit (and
      OOo Writer, and Firefox) return the first word. I think the
      idea is that there *is* a word *at* the specified offset.

      From the test case I described above:

        i       Gedit WORD_END          WebKit WORD_END
        0       ('This', 0, 4)          ('', 0, 0)
        1       ('This', 0, 4)          ('', 0, 0)
        2       ('This', 0, 4)          ('', 0, 0)
        3       ('This', 0, 4)          ('', 0, 0)

      A similar issue can be seen with getTextBeforeOffset. Both
      Gedit and WebKit return ('', 0, 0) as expected when i is the
      offset of a character in the first word, but WebKit continues
      to do so until i seems to be the offset of the end of the 2nd
      word:

        i       Gedit WORD_END  WebKit WORD_END
        3       ('', 0, 0)      ('', 0, 0)
        4       ('This', 0, 4)  ('', 0, 0)
        5       ('This', 0, 4)  ('', 0, 0)
        6       ('This', 0, 4)  ('', 0, 0)

    - Similarly for getTextAtOffset(i, TEXT_BOUNDARY_WORD_START)
      where i is an offset of a character in the final word:

        i       Gedit WORD_START        WebKit WORD_START
        23      ('test.', 23, 28)       ('', 0, 0)
        24      ('test.', 23, 28)       ('', 0, 0)
        25      ('test.', 23, 28)       ('', 0, 0)
        26      ('test.', 23, 28)       ('', 0, 0)
        27      ('test.', 23, 28)       ('', 0, 0)

    - There's also a difference with TEXT_BOUNDARY_WORD_END when
      the offset is for a space:

        i       Gedit WORD_END          WebKit WORD_END
        7       (' another', 7, 15)     (' is', 4, 7)
        15      (', silly', 15, 22)     (' another', 7, 15)
        22      (' test', 22, 27)       (', silly', 15, 22)

      Firefox does the same thing as Gedit. OOo Writer returns
      ('', 0, 0), but don't think that makes as much sense.

    - Calling getTextAfterOffset with either word boundary type
      will eventually crash the GtkLauncher with the following
      error:

      GLib-ERROR **: /build/buildd/glib2.0-2.20.1/glib/gmem.c:136:
      failed to allocate 4294967269 bytes
      aborting...
      Aborted

      See test case below.

  * TEXT_BOUNDARY_LINE_{START,END} have not been implemented,
    as you indicated in your comments.

  * TEXT_BOUNDARY_SENTENCE_END when used with an offset in the
    first/only sentence results in ('', 0, 0) instead of that
    sentence.

  * TEXT_BOUNDARY_SENTENCE_START when used with an offset in the
    first/only sentence results in GtkLauncher crashing with the
    above Glib error.

    See test case below.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tests to reproduce the aforementioned crashes:

1. Open the attached test case in GtkLauncher.

2. Using Accerciser, select the text object in the tree on the left. 

3. In the IPython console:

   Test 1: 
   acc.queryText().getTextAtOffset(0, TEXT_BOUNDARY_SENTENCE_START)

   Test 2: 
   acc.queryText().getTextAfterOffset(26, TEXT_BOUNDARY_WORD_START)

Hope this helps!


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