Inspector is not showing timing information because the response does not carry the required information due to changes added in r116160. Patch to follow.
Created attachment 206106 [details] Patch
(In reply to comment #0) > Inspector is not showing timing information because the response does not carry the required information due to changes added in r116160. Patch to follow. Okay. The soup backend bits look reasonable. I don't know about the WebTiming test.
(In reply to comment #2) > (In reply to comment #0) > > Inspector is not showing timing information because the response does not carry the required information due to changes added in r116160. Patch to follow. > > Okay. The soup backend bits look reasonable. I don't know about the WebTiming test. BTW I've just checked that the similar fix was added to Blink.
(In reply to comment #2) > (In reply to comment #0) > > Inspector is not showing timing information because the response does not carry the required information due to changes added in r116160. Patch to follow. > > Okay. The soup backend bits look reasonable. I don't know about the WebTiming test. ap, andersca: any thoughts?
Adding Brady who might have an opinion on the matter. The fix is already pre-reviewed, just need someone to double-check that the test changes are OK.
Ping reviewers
Comment on attachment 206106 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=206106&action=review > LayoutTests/http/tests/misc/webtiming-ssl-expected.txt:7 > -FAIL timing.secureConnectionStart should be >= timing.connectStart. Was 0 (of type number). > +PASS timing.secureConnectionStart is >= timing.connectStart Okay. This looks okay to me, but won't this start failing on other ports now? If not, then do they have cascading expectations to cover this? If they do, doesn't it make sense to remove those as well?
(In reply to comment #7) > (From update of attachment 206106 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=206106&action=review > > > LayoutTests/http/tests/misc/webtiming-ssl-expected.txt:7 > > -FAIL timing.secureConnectionStart should be >= timing.connectStart. Was 0 (of type number). > > +PASS timing.secureConnectionStart is >= timing.connectStart > > Okay. This looks okay to me, but won't this start failing on other ports now? If not, then do they have cascading expectations to cover this? If they do, doesn't it make sense to remove those as well? Mac, Win and Wincairo ports explicitly disable this test, efl/gtk will share this fix, so the only one remaining is Qt which does not support WEB_TIMING AFAIK...
Comment on attachment 206106 [details] Patch Thanks. This has been sitting long enough.
Committed r154727: <http://trac.webkit.org/changeset/154727>