+some service worker folks - anyone have cycles to help look at these failures?

To clarify, the tests are failing when this change[1] is made to Mojo, implying there must be some bad ordering assumptions somewhere in service worker or test code.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/1145692

Cool thanks. I'll try to look this week. Looks like the failure is:

FAIL Navigation Preload Resource Timing. assert_equals: performance.getEntriesByName() must returns one PerformanceResourceTiming entry for the navigation preload. expected 1 but got 0

I investigated this a bit. It seems that SWContextClient::RespondToFetchEvent() is called before SWContextClient::OnNavigationPreloadComplete when we apply the patch mentioned in Comment 1.

w/o patch:
SWContextClient::OnNavigationPreloadResponse
-> SWContextClient::OnNavigationPreloadComplete
-> SWContextClient::RespondToFetchEvent

w/ patch:
SWContextClient::OnNavigationPreloadResponse
-> SWContextClient::RespondToFetchEvent
-> SWContextClient::OnNavigationPreloadComplete

Attaching trace files and screenshots.

Deleted: trace_with_patch.json.gz 290 KB

trace_with_patch.json.gz 290 KB Download

Deleted: trace_without_patch.json.gz 256 KB

trace_without_patch.json.gz 256 KB Download

Deleted: with_patch.png 120 KB

	with_patch.png 120 KB View Download

Deleted: without_patch.png 126 KB

	without_patch.png 126 KB View Download

Interesting. In theory we should be able to handle both patterns. OnNavigationPreloadResponse is called when the headers arrive at the browser, OnNavigationPreloadComplete is when the body finished, and RespondToFetchEvent is called when the promise passed to respondWith() resolves (if it's event.preloadResponse, then it's when the headers arrive). But maybe there is brittleness here.

Thanks for the info! I think I have a fix for the test.
https://chromium-review.googlesource.com/c/chromium/src/+/1170679

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/028965323141e0562a1066ab892c150334ee0db0

commit 028965323141e0562a1066ab892c150334ee0db0
Author: Kenichi Ishibashi <bashi@chromium.org>
Date: Thu Aug 16 01:24:01 2018

service worker: Fix navigation-preload/resource-timing.https.html test

Before this CL, this test tried to get performance entries right after
Response#text() is resolved, but Chrome doesn't guarantee that there
will be a performance entry for the response at that point. This CL
changes the test to use PerformanceObserver so that we can make sure
that there will be a performance entry for the response.

Bug:  872078 
Change-Id: I6ecfcb8e0721df541d5a32f56ec4c062efbffdae
Reviewed-on: https://chromium-review.googlesource.com/1170679
Commit-Queue: Kenichi Ishibashi <bashi@chromium.org>
Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#583483}
[modify] https://crrev.com/028965323141e0562a1066ab892c150334ee0db0/third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/navigation-preload/resources/resource-timing-worker.js

I think the test was fixed. Let me know if you still see failures.