I suspect that the reason WebKitEfl exposes all tables (data and layout) as AccessibilityTables is because they inherited that expectation from WebKitGtk. As I indicated in bug 144896, there doesn't seem to be much point in continuing to override WebCore Accessibility -- at least not for WebKitGtk. If the only reason you do it in Efl is because we <strike>do</strike> did it in Gtk, it might be nice to get rid of this platform difference. (BTW, I'd propose a patch myself but I'm having trouble at the moment building WebKitEfl. And the tests that spit out all attributes, including bounding boxes, are something one cannot take an educated guess at.)
<rdar://problem/20911606>
(In reply to comment #0) > (BTW, I'd propose a patch myself but I'm having trouble at the moment > building WebKitEfl. And the tests that spit out all attributes, including > bounding boxes, are something one cannot take an educated guess at.) I take a look the Bug 144896. First of all the updated expectations have been marked to *failure* in EFL port. http://trac.webkit.org/browser/trunk/LayoutTests/platform/efl/TestExpectations#L1824 I'm not sure if EFL port needs to do something further yet. If you have patch for EFL port, please upload it to take a look. > (BTW, I'd propose a patch myself but I'm having trouble at the moment building WebKitEfl. Please following below instruction to build EFL port. Build step is similar to GTK port. 1. ./Tools/efl/install-dependencies 2. ./Tools/Scripts/build-webkit --efl --update-efl 3. ./Tools/Scripts/run-webkit-tests --efl test-path (e.g. fast/forms/plaintext-mode-1.html)
Created attachment 266890 [details] Patch
Comment on attachment 266890 [details] Patch Clearing flags on attachment: 266890 Committed r193813: <http://trac.webkit.org/changeset/193813>
All reviewed patches have been landed. Closing bug.