RESOLVED FIXED 151101
UI-side scripts in WebKitTestRunner should wait until event handling completes before finishing
https://bugs.webkit.org/show_bug.cgi?id=151101
Summary UI-side scripts in WebKitTestRunner should wait until event handling complete...
Wenson Hsieh
Reported 2015-11-10 09:00:09 PST
WebKitTestRunner may still crash in the scenario where a marker event is dequeued and handled after uiScriptComplete has been called. While this scenario should never happen when running iOS interaction tests serially on a single simulator, this seems to happen occasionally when tests are run in parallel. We can fix this by making UI script execution smart enough to defer script completion until all events (currently tap, double tap and hardware keyboard) have been handled.
Attachments
Patch (24.25 KB, patch)
2015-11-10 10:53 PST, Wenson Hsieh
no flags
Archive of layout-test-results from ews106 for mac-mavericks-wk2 (679.40 KB, application/zip)
2015-11-10 11:44 PST, Build Bot
no flags
Patch (26.94 KB, patch)
2015-11-10 22:49 PST, Wenson Hsieh
no flags
Patch (26.74 KB, patch)
2015-11-11 07:27 PST, Wenson Hsieh
simon.fraser: review+
Wenson Hsieh
Comment 1 2015-11-10 09:08:58 PST
Wenson Hsieh
Comment 2 2015-11-10 10:53:43 PST
Tim Horton
Comment 3 2015-11-10 11:03:07 PST
Comment on attachment 265200 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=265200&action=review > Tools/WebKitTestRunner/UIScriptContext/Bindings/UIScriptController.idl:53 > - void uiScriptComplete(DOMString result); > + void uiScriptCompleteAfterHandlingEvents(DOMString result); This probably could have been an implementation detail of uiScriptComplete instead of requiring a rename. We don't list all the other things that happen between calling this and actually being /done/. > Tools/WebKitTestRunner/UIScriptContext/UIScriptContext.h:53 > unsigned prepareForAsyncTask(JSValueRef taskCallback); > + unsigned prepareForAsyncTaskBlockingScriptCompletion(JSValueRef taskCallback); Do we ever want async tasks *not* to block uiScriptComplete? Is it ever bad if they do? It would be nice to only have one that always does the right thing, to make it harder to write a broken test (and not change the name like above).
Build Bot
Comment 4 2015-11-10 11:43:59 PST
Comment on attachment 265200 [details] Patch Attachment 265200 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/411197 New failing tests: fast/harness/concurrent-ui-side-scripts.html fast/harness/ui-side-scripts.html
Build Bot
Comment 5 2015-11-10 11:44:02 PST
Created attachment 265208 [details] Archive of layout-test-results from ews106 for mac-mavericks-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews106 Port: mac-mavericks-wk2 Platform: Mac OS X 10.9.5
Wenson Hsieh
Comment 6 2015-11-10 22:49:25 PST
Simon Fraser (smfr)
Comment 7 2015-11-10 23:01:34 PST
Comment on attachment 265272 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=265272&action=review > Tools/WebKitTestRunner/UIScriptContext/UIScriptContext.h:49 > +const unsigned minimumPersistentCallbackID = 1000; > +typedef enum { > + CallbackTypeNonPersistent, > + CallbackTypeWillBeginZooming = minimumPersistentCallbackID, > + CallbackTypeDidEndZooming = minimumPersistentCallbackID + 1, > + CallbackTypeDidShowKeyboard = minimumPersistentCallbackID + 2, > + CallbackTypeDidHideKeyboard = minimumPersistentCallbackID + 3 > +} CallbackType; I think it's better to reserve the low range for persistent callbacks; that way, the upper bound for other callbacks is much higher.
Wenson Hsieh
Comment 8 2015-11-11 07:21:07 PST
Comment on attachment 265272 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=265272&action=review >> Tools/WebKitTestRunner/UIScriptContext/UIScriptContext.h:49 >> +} CallbackType; > > I think it's better to reserve the low range for persistent callbacks; that way, the upper bound for other callbacks is much higher. That makes sense -- changed to use minimumNonPersistentCallbackID.
Wenson Hsieh
Comment 9 2015-11-11 07:27:13 PST
Simon Fraser (smfr)
Comment 10 2015-11-11 09:51:33 PST
Comment on attachment 265286 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=265286&action=review > Tools/WebKitTestRunner/UIScriptContext/UIScriptContext.cpp:158 > + m_uiScriptResultsPendingCompletion.add(m_currentScriptCallbackID, result ? JSStringRetain(result) : result); : nullptr I think. > Tools/WebKitTestRunner/UIScriptContext/UIScriptContext.cpp:188 > + for (WTF::KeyValuePair<unsigned, Task> entry : m_callbacks) { auto > Tools/WebKitTestRunner/UIScriptContext/UIScriptContext.h:42 > +const unsigned minimumNonPersistentCallbackID = 1000; How about firstNonPersistentCallbackID and a blank line after this.
Wenson Hsieh
Comment 11 2015-11-11 10:15:53 PST
Note You need to log in before you can comment on or make changes to this bug.