[webkit-reviews] review granted: [Bug 184893] [iOS] API test ScrollViewInsetTests.InnerHeightWithLargeTopContentInset is a flaky failure : [Attachment 341623] Patch

[bugzilla-daemon at webkit.org]

Wenson Hsieh <wenson_hsieh at apple.com> has granted Chris Dumez
<cdumez at apple.com>'s request for review:
Bug 184893: [iOS] API test
ScrollViewInsetTests.InnerHeightWithLargeTopContentInset is a flaky failure
https://bugs.webkit.org/show_bug.cgi?id=184893

Attachment 341623: Patch

https://bugs.webkit.org/attachment.cgi?id=341623&action=review




--- Comment #4 from Wenson Hsieh <wenson_hsieh at apple.com> ---
Comment on attachment 341623
  --> https://bugs.webkit.org/attachment.cgi?id=341623
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=341623&action=review

> Tools/TestWebKitAPI/Tests/ios/ScrollViewInsetTests.mm:81
> +    int tries = 0;

Do we really need a max number of tries here? I think letting it just time out
isn't a bad thing, per se...

Also, perhaps this would just work if we waited until the next *visible content
rect* update instead of the next remote layer tree commit, since visible
content rect update is the mechanism by which we account for scroll view
content insets. It's possible we don't even need the "wait-until-done" loop!
There's WKWebView SPI to do this: see -_doAfterNextVisibleContentRectUpdate:.