Bug 142381 – [GTK] webkit_web_view_get_tls_info sometimes fails inexplicably

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: WebKitGTK

[Michael Catanzaro]

Created attachment 248034 [details]
test program

I don't know what's wrong here yet, but it's causing our lock icon to not appear on secure pages. I verified TLS is actually being used with Wireshark.

Attached is a test program that just reloads https://static.gnome.org/error-500/500.html over and over in one web view, then calls webkit_web_view_get_tls_info and prints what it gets. My output looks like this:

result = TRUE, certificate=0xf09090, errors=0
result = TRUE, certificate=0xf08db0, errors=0
result = TRUE, certificate=0xf09090, errors=0
result = FALSE, certificate=(nil), errors=0
result = TRUE, certificate=0xfb9890, errors=0
result = TRUE, certificate=0xfb9d50, errors=0
result = FALSE, certificate=(nil), errors=0
result = TRUE, certificate=0xfb98f0, errors=0
result = TRUE, certificate=0xfb9890, errors=0
result = TRUE, certificate=0xfb9d50, errors=0
result = TRUE, certificate=0xf09270, errors=0
result = FALSE, certificate=(nil), errors=0
result = FALSE, certificate=(nil), errors=0
result = TRUE, certificate=0xfb9b30, errors=0
result = TRUE, certificate=0xfb9c30, errors=0
result = FALSE, certificate=(nil), errors=0
result = TRUE, certificate=0xf08c90, errors=0
result = FALSE, certificate=(nil), errors=0
result = FALSE, certificate=(nil), errors=0

So there is some race. I will debug this more another time.

I changed the URL to https://eff.org, and here is the result:

result = TRUE, certificate=0x1b0aa10, errors=0
result = FALSE, certificate=(nil), errors=0
result = FALSE, certificate=(nil), errors=0
result = FALSE, certificate=(nil), errors=0
result = FALSE, certificate=(nil), errors=0
result = FALSE, certificate=(nil), errors=0
result = FALSE, certificate=(nil), errors=0
result = FALSE, certificate=(nil), errors=0

eff.org is much slower to reload.

[Michael Catanzaro]

Created attachment 248035 [details]
test program

[Michael Catanzaro]

This is fixed in trunk, probably by r194890.

*** This bug has been marked as a duplicate of bug 142375 ***