Bug 206313

Summary: fast/forms/ios/zoom-after-input-tap-wide-input.html is timing out
Product: WebKit Reporter: Simon Fraser (smfr) <simon.fraser>
Component: New BugsAssignee: 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 Flags
Patch none

Simon Fraser (smfr)
Reported 2020-01-15 13:42:48 PST
fast/forms/ios/zoom-after-input-tap-wide-input.html is timing out
Attachments
Patch (7.58 KB, patch)
2020-01-15 13:46 PST, Simon Fraser (smfr) 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Simon Fraser (smfr)
Comment 1 2020-01-15 13:46:49 PST
Created attachment 387839 [details] Patch
Simon Fraser (smfr)
Comment 2 2020-01-15 13:47:19 PST
rdar://problem/52959633
Wenson Hsieh
Comment 3 2020-01-15 14:02:35 PST
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.
Alexey Proskuryakov
Comment 4 2020-01-15 15:17:59 PST
Wenson’s comment makes it sound more like an r- to me.
Wenson Hsieh
Comment 5 2020-01-15 15:37:36 PST
(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).
Alexey Proskuryakov
Comment 6 2020-01-15 17:24:16 PST
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.
Simon Fraser (smfr)
Comment 7 2020-01-15 17:24:56 PST
Isn't that true when any of the "reset" stuff fails?
Alexey Proskuryakov
Comment 8 2020-01-15 19:12:09 PST
I would think so, otherwise why would we bother resetting it?
WebKit Commit Bot
Comment 9 2020-01-16 11:10:45 PST
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.
WebKit Commit Bot
Comment 10 2020-01-16 11:10:52 PST
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.
WebKit Commit Bot
Comment 11 2020-01-16 11:27:48 PST
Comment on attachment 387839 [details] Patch Clearing flags on attachment: 387839 Committed r254699: <https://trac.webkit.org/changeset/254699>
WebKit Commit Bot
Comment 12 2020-01-16 11:27:50 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.