[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