| Summary: | Network connection fails with error 53 just after NetworkProcess resumes | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Ali Juma <ajuma> | ||||
| Component: | WebKit API | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | NEW --- | ||||||
| Severity: | Normal | CC: | achristensen, ap, cdumez, jzw, webkit-bug-importer | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | WebKit Local Build | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
GitHub issue that points to a related issue where firing network requests as the process if coming back into the foreground would produce the same error code 53: https://github.com/AFNetworking/AFNetworking/issues/4279 I have no idea why this may be, but it is infinitely easier to reproduce this when you have the Console.app connected to the iOS device. |
Created attachment 371215 [details] Test app that reproduces the bug Steps to reproduce on an iOS device: 1) Create a WKWebView and load some content into that view 2) Hide that view, triggering its NetworkProcess to get suspended 3) Wait 10-20 seconds 4) Create another WKWebView using the same WKWebViewConfiguration (and hence the same WKProcessPool and NetworkProcess) and call loadRequest Sometimes, the load at (4) will fail and an error will be logged: “com.apple.WebKit.Networking 27551 nw_protocol_boringssl_error(1584) <private>[0x109155030] Lower protocol stack error: 53” This only happens on-device. To reproduce this, it seems to be critical that: -both WKWebViews use the same WKProcessPool -the first WKWebView is hidden and its processes suspended -the second WKWebView starts a loadRequest around the same time that the NetworkProcess resumes