Bug 100010 - [EFL][WK2] fast/repaint/delete-into-nested-block.html and fast/repaint/4776765.html are flaky
Summary: [EFL][WK2] fast/repaint/delete-into-nested-block.html and fast/repaint/477676...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit EFL (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Raphael Kubo da Costa (:rakuco)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-22 09:43 PDT by Raphael Kubo da Costa (:rakuco)
Modified: 2012-10-29 02:39 PDT (History)
3 users (show)

See Also:


Attachments
Patch (1.87 KB, patch)
2012-10-24 04:39 PDT, Raphael Kubo da Costa (:rakuco)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Raphael Kubo da Costa (:rakuco) 2012-10-22 09:43:17 PDT
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.
Comment 1 Raphael Kubo da Costa (:rakuco) 2012-10-23 08:33:06 PDT
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 :-)
Comment 2 Raphael Kubo da Costa (:rakuco) 2012-10-24 04:39:56 PDT
Created attachment 170362 [details]
Patch
Comment 3 Raphael Kubo da Costa (:rakuco) 2012-10-24 05:38:14 PDT
Comment on attachment 170362 [details]
Patch

Clearing flags on attachment: 170362

Committed r132342: <http://trac.webkit.org/changeset/132342>
Comment 4 Raphael Kubo da Costa (:rakuco) 2012-10-24 05:38:22 PDT
All reviewed patches have been landed.  Closing bug.
Comment 5 Dominik Röttsches (drott) 2012-10-24 07:21:59 PDT
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
Comment 6 Raphael Kubo da Costa (:rakuco) 2012-10-29 02:39:25 PDT
(In reply to comment #5)
> This causes some extra output in frame-tab-focus.html

I've filed bug 100646 to track this.