Bug 118395 – [Soup] WebTiming information not shown in the inspector

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Sergio Villar Senin]

Inspector is not showing timing information because the response does not carry the required information due to changes added in r116160. Patch to follow.

[Sergio Villar Senin]

Created attachment 206106 [details]
Patch

[Martin Robinson]

(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.

[Sergio Villar Senin]

(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.

[Sergio Villar Senin]

(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?

[Sergio Villar Senin]

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.

[Sergio Villar Senin]

Ping reviewers

[Martin Robinson]

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?

[Sergio Villar Senin]

(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...

[Martin Robinson]

Comment on attachment 206106 [details]
Patch

Thanks. This has been sitting long enough.

[Sergio Villar Senin]

Committed r154727: <http://trac.webkit.org/changeset/154727>