[Webkit-unassigned] [Bug 27011] [Gtk] Implement support for get_index_in_parent

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jul 8 12:07:45 PDT 2009


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





--- Comment #3 from Joanmarie Diggs <joanmarie.diggs at gmail.com>  2009-07-08 12:07:45 PDT ---
(In reply to comment #1)
> Created an attachment (id=32456)
 --> (https://bugs.webkit.org/attachment.cgi?id=32456) [details]
> getindexinparent.patch
> 
> This implements the function, but the particular testcase you mention does not
> work because the object hierarchy is not quite right in Google's case (the Map
> object has a dummy 'label' parent).

Actually, my test case does work with your patch. :-) Ignore the "label"
graphic in Accerciser. The Role column says it's a link. If I highlight the
accessible of ROLE_LINKN for "Maps" (not the accessible text object which is
the child of that link), acc.getIndexInParent() returns 3 as expected. Yea!

I did find another oddity on Google though. If you look at the hierarchy in
Accerciser, you should see:

document frame
  panel
      text
      link 
      link
      link
      link
      link
      link
      link
  panel
  panel
  panel
  panel
  panel
  panel
  panel

(I expanded the first panel just to be sure we're on the same page so to
speak.)

Looking strictly at the panels/immediate children of the document frame, try
acc.getIndexInParent()

I get:
1st child: 0
2nd child: 1
3rd child: 0
4th child: 0
5th child: 1
6th child: 2
7th child: 4
8th child: 5

So independent of the list rendering issue I reported in my previous comment, I
think there may be something not quite right about your patch. Sorry!

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



More information about the webkit-unassigned mailing list