Bug 206313 - fast/forms/ios/zoom-after-input-tap-wide-input.html is timing out
Summary: fast/forms/ios/zoom-after-input-tap-wide-input.html is timing out
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Simon Fraser (smfr)
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-01-15 13:42 PST by Simon Fraser (smfr)
Modified: 2020-01-16 11:27 PST (History)
5 users (show)

See Also:

Attachments
Patch (7.58 KB, patch)
2020-01-15 13:46 PST, Simon Fraser (smfr) 		no flags Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

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