[Webkit-unassigned] [Bug 186919] New: Navigation Timing data is corrupt in WebView (UIWebView/WKWebView)

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jun 22 07:09:55 PDT 2018


            Bug ID: 186919
           Summary: Navigation Timing data is corrupt in WebView
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: iPhone / iPad
                OS: iOS 11
            Status: NEW
          Severity: Major
          Priority: P2
         Component: WebCore Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: krinklemail at gmail.com

iOS 8.0 introduced support for the Navigation Timing API, which had issues and was removed in 8.1, then re-introduced in iOS 9.0 with different issues. These were fixed for the Mobile Safari app in 9.1, but WebView remained a source of invalid Navigation Timing data and has continued to have the same issues to this day in iOS 11.

Downstream report: https://phabricator.wikimedia.org/T190977

Specifically, the following two types of data corruption are the most common in data received from Wikipedia users:

* fetchStart went backwards from unloadEventEnd.
* responseStart went backwards from requestStart.

Test url:

Steps to reproduce:
Intermittent, but loading this page within an app (e.g. Apple Dictionary, Facebook Messenger, Feedly, etc.), either directly from a native view, or as secondary navigation after initially entering an embedded view, most often when refreshing the view, will eventually cause the error to occur.

For Wikipedia, the data from Navigation Timing API is central to measuring performance from users. iOS WebView is a significant source of traffic (at between 1% and 2% of Wikipedia page views, per Jan-May 2018). Unfortunately, (almost) all of this data is discarded before recording because it does not pass a basic data compliance check.

Here's a dump from the logs of our data validation service from last few hours (sorted by frequency)

| Rank | Hits | Normalised message
| ---- | ---- | ------------------
| #1   | 1987 | (is_compliant:443) Discarding event because responseEnd is out of order [{'os_minor': '4', 'os_major': '11', 'device_family': 'iPhone', 'os_family': 'iOS', 'browser_minor': '0', 'browser_major': '11', 'browser_family': 'Mobile Safari'}]
| #2   | 1566 | (is_compliant:443) Discarding event because requestStart is out of order [{'os_minor': '3', 'os_major': '9', 'device_family': 'iPad', 'os_family': 'iOS', 'browser_minor': '0', 'browser_major': '9', 'browser_family': 'Mobile Safari'}]
| #3   |  821 | (is_compliant:443) Discarding event because responseEnd is out of order [{'os_minor': '3', 'os_major': '11', 'device_family': 'iPhone', 'os_family': 'iOS', 'browser_minor': '0', 'browser_major': '11', 'browser_family': 'Mobile Safari'}]
| #4   |  786 | (is_compliant:443) Discarding event because requestStart is out of order [{'os_minor': '3', 'os_major': '9', 'device_family': 'iPhone', 'os_family': 'iOS', 'browser_minor': '0', 'browser_major': '9', 'browser_family': 'Mobile Safari'}]
| #5   |  468 | (is_compliant:443) Discarding event because responseEnd is out of order [{'os_minor': '2', 'os_major': '11', 'device_family': 'iPhone', 'os_family': 'iOS', 'browser_minor': '0', 'browser_major': '11', 'browser_family': 'Mobile Safari'}]

There used to be a Chrome entry in the top 5 as well (Chrome 62 and earlier produced invalid timing data on redirected navigations), but that was fixed per https://bugs.chromium.org/p/chromium/issues/detail?id=813889.

At this time, Mobile Safari (WebView) accounts for 98% of navigation timing errors.

See also:
* https://bugs.webkit.org/show_bug.cgi?id=184363
* Downstream investigation: https://phabricator.wikimedia.org/T190977
* Similar issue in Chromium (affecting redirects only, FIXED) - https://bugs.chromium.org/p/chromium/issues/detail?id=813889
* Wikipedia performance data validation - https://grafana.wikimedia.org/dashboard/db/eventlogging-schema?var-schema=NavigationTiming (currently around 0.3 errors per second, from a sampling of 1:1000 page views)

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180622/41f328d1/attachment-0001.html>

More information about the webkit-unassigned mailing list