[Webkit-unassigned] [Bug 72811] [Gtk] No accessible caret-moved events found in certain content

[bugzilla-daemon at webkit.org]

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





--- Comment #11 from Mario Sanchez Prada <msanchez at igalia.com>  2012-08-20 01:07:08 PST ---
(From update of attachment 159321)
View in context: https://bugs.webkit.org/attachment.cgi?id=159321&action=review

>> Source/WebCore/accessibility/gtk/AccessibilityObjectAtk.cpp:85
>> +    if (ariaRoleAttribute() != UnknownRole || parent->ariaRoleAttribute() != UnknownRole)
> 
> It seems that just asking the parent if it's not an unknown wouldn't account for
> <div><div><span>element</span></div></div>, or anything with nested unknowns. I don't see what's special about a parent having unknown role, but not a grandparent.

What about using parentObjectUnignored()? I think that would cover the issue with "nested unknowns" Chris mentioned. Not sure if it would be good enough, though

>> Source/WebCore/accessibility/gtk/AccessibilityObjectAtk.cpp:91
>> +    if ((node() && node()->hasTagName(spanTag)) || (renderObject && renderObject->isAnonymousBlock())) {
> 
> It seems weird to special case spanTag here. That seems like a level of detail that platform wrapper shouldn't have to know. 
> It also seems weird that these isBody checks are inside this block. Seems like you could just check for that outside this block.
> 
> The logic change here appears to be to cause <spans> and anonymous render blocks to be ignored, but doesn't WebCore do that already?

I agree with Chris's concerns here. Also, I wonder whether this would work as expected for those cases where divs are displayed inline (<div style="display:inline;">), which I agree are not the regular use case of HTML, but it happens some time.

Maybe there's a better way to check this (and get the same results) by checking the computed style for the render object?

> Source/WebKit/gtk/tests/testatk.c:413
> +    g_assert_cmpstr(text, ==, "Block span in a link\nInline span in a link");

You're leaking memory for text here. As atk_text_get_text returns newly allocated memory, you should ensure you call g_free before reusing that variable.

It seems the same issues was present in this function prior to this patch, though. This patch could be a good moment to fix them (I'd put them in lines 375 and 386)

> Source/WebKit/gtk/tests/testatk.c:426
> +    g_assert_cmpstr(text, ==, "Block span in a heading\nInline span in a heading");

Same leak here

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