| Summary: | fast/forms/ios/zoom-after-input-tap-wide-input.html is timing out | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Simon Fraser (smfr) <simon.fraser> | ||||
| Component: | New Bugs | Assignee: | Simon Fraser (smfr) <simon.fraser> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | ap, commit-queue, simon.fraser, webkit-bug-importer, wenson_hsieh | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | WebKit Nightly Build | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Simon Fraser (smfr)
2020-01-15 13:42:48 PST
Created attachment 387839 [details]
Patch
Comment on attachment 387839 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=387839&action=review > Tools/WebKitTestRunner/TestController.cpp:1090 > + return false; It's not obvious to me what effects bailing early here in TestController::resetPreferencesToConsistentValues would have on the subsequent test, since we're only half done resetting test harness state (among other things, we'd skip waiting for about:blank to load). Perhaps we should consider either raising an exception (and crashing) or simply continuing with the rest of the function here. Wenson’s comment makes it sound more like an r- to me. (In reply to Alexey Proskuryakov from comment #4) > Wenson’s comment makes it sound more like an r- to me. Simon told me over Slack that something else (presumably the Python script) will kill the test in the event of a timeout anyways (which would address my concerns). Still, why would we want to leave the process in such a dangerous state? If resetting to consistent state didn't work, WebKitTestRunner should just terminate immediately, leaving no possibility for leaking state, even if someone makes a mistake in the future. Isn't that true when any of the "reset" stuff fails? I would think so, otherwise why would we bother resetting it? The commit-queue encountered the following flaky tests while processing attachment 387839 [details]: media/track/track-cues-sorted-before-dispatch.html bug 206225 (authors: simon.pena@samsung.com and vcarbune@chromium.org) The commit-queue is continuing to process your patch. The commit-queue encountered the following flaky tests while processing attachment 387839 [details]: imported/w3c/web-platform-tests/IndexedDB/interleaved-cursors-large.html bug 201849 The commit-queue is continuing to process your patch. Comment on attachment 387839 [details] Patch Clearing flags on attachment: 387839 Committed r254699: <https://trac.webkit.org/changeset/254699> All reviewed patches have been landed. Closing bug. |