It looks like there's some problem with the focus code in WTR: when fast/repaint/4774354.html (which calls focus() in an iframe) is run before those tests, it looks like the view itself (or the main frame, I don't know) is not considered focused anymore, and the focus ring is not drawn around the <div>s.
So this is how things are working so far: o TestController::resetStateToConsistentValues() calls PlatformWebView::focus(), which calls evas_object_focus_set(..., true) before every test is run. o Before running the first test (fast/repaint/4774354.html), this call to evas_object_focus_set() makes the main view receive focus, and WebPageProxy::viewStateDidChange() ends up making the web process call WebPage::setFocused(true), which is the normal flow anyway. o This test then focuses an iframe it has via `window.frames[0].focus'. This makes WebCore::FrameSelection::setFocused(false) be called for the main frame's frame selection, and WebCore::FrameSelection::setFocused(true) be called for the iframe's frame selection. o When the test finishes, the main frame's frame selection is still internally in an unfocused state, however Evas considers the main view to still be focused. o fast/repaint/delete-into-nested-block.html is then run, and when WebCore then queries the main frame's FrameSelection to see it is focused in order to decide whether to draw the focus ring around the <div>, that query returns false and the focus ring is not drawn. o WebCore::FrameSelection::setFocused(true) is not called despite TestController::resetStateToConsistentValues() and thus PlatformWebView::focus() being called before each test because evas_object_focus_set(..., true) becomes a no-op since Evas thinks the main view (an Evas_Object) is still visible, as we had already called evas_object_focus_set(..., true) before. WebPageProxy::viewStateDidChange() is then not called, and the main frame's frame selection state is never reset to true. That problem does not affect DRT because we call ewk_frame_feed_focus_in() there, whose sole responsibility is to manually call WebCore::FocusController::setFocusedFrame() on the main frame, and this triggers a call to WebCore::FrameSelection::setFocused(true). The next step is thinking of a solution :-)
Created attachment 170362 [details] Patch
Comment on attachment 170362 [details] Patch Clearing flags on attachment: 170362 Committed r132342: <http://trac.webkit.org/changeset/132342>
All reviewed patches have been landed. Closing bug.
This causes some extra output in frame-tab-focus.html - shouldn't we fix this in a way that does not require a platform specific result for this test? Going to skip for now. --- /home/buildslave-1/webkit-buildslave/efl-linux-64-debug-wk2/build/layout-test-results/fast/events/frame-tab-focus-expected.txt +++ /home/buildslave-1/webkit-buildslave/efl-linux-64-debug-wk2/build/layout-test-results/fast/events/frame-tab-focus-actual.txt @@ -1,6 +1,8 @@ This page tests tabbing between subframes. To test, click on this text to focus the main window. Then press Tab 7 times, then Shift-Tab 7 times, which should move focus forward and backward through all inputs and frames. Then press Option-Tab 11 times and Shift-Option-Tab 11 times, which should move focus forward and backward through all inputs, frames, and links. [tabindex of one] [tabindex of three] [tabindex of two] [tabindex of three] +main window: window blurred +main window: window focused Tabbing forward... main window: INPUT #2 (tabindex=2) focused
(In reply to comment #5) > This causes some extra output in frame-tab-focus.html I've filed bug 100646 to track this.