When working on WebKit and the platform layer you come to a point where your primary browser is going to be WebKit based (or already is because you use Safari, OmniWeb,…). If you happen to use a platform that is not developed by Apple (Qt, Gtk+, Wx) you are going to be the first to see certain issues. I’m currently in this fantastic situation and have issues to see, understand and resolve.

This is a brief summary of two issues Simon and me were looking into at the wonderful 24C3 this year. We have looked into GMail and Yahoo Mail.

The Yahoo issue started with the attempt to sign into my ancient account, and this time the issue wasn’t to remember my password. Our Qt Demo Browser went into a infinite loop of redirections. So what was wrong? The obvious thing to blame is our networking implementation and the brand new QNetworkAccessManager and related classes. And yes some issues were found in our networking implementation. For redirections we have told WebCore more than once that a redirection is happening, we have missed one redirection code. To cut a long story short, this didn’t fix the issue. Cookies are always important so we checked them, fall victim of wireshark as it is truncating the decoded HTTP header and it looked like we didn’t send the full cookie string. It fooled us for a second or two and then we remembered our HTTP and Cookie implementation must be perfect as Thiago wrote most of it. So I started to find out where this redirection gets triggered, joy it came from a timer, so who started it? And we saw that it was coming from JS, so it was something embedded into the site. We signed in with https://mail.yahoo.com, got redirectred to a US server, then to a German one and then sent back to http://mail.yahoo.com. Note that the last redirection is going from http to https. So once again the WebKit Web Inspector came to rescue and we searched for “http://mail.yahoo.com” in the sourcecode view and two hits where revealed, after not starting the redirection timer when it is going to http://mail.yahoo.com. The second hit was interesting as it pointed to a piece of javascript code that was asking the DOM for cookies. Our CookieJar implementation was a bit selfish as it didn’t want to share all relevant cookies with the DOM but only one, after convincing it to return all relevant Cookies the login and sending mails finally worked!

The Gmail issue. You can sign in to Gmail as we pass the google cookie test, you see the full version of Gmail and we were not able to click any links. The JS Code google is sending is highly obfusicated so debugging is no fun at all, we went for the easy solution and updated our User Agent string, magic happened and we were served another version of it and it made our browser terminate in an assert in WebCore::FrameLoader. The next easy thing was to git merge the Safari-3-Branch into QtWebKit, recompiling, login, ASSERT, *joy*. With the usual and fantastic help of the apple folk I got pointed to #15765 and yes we were hitting this bug. I can tell you reducing Gmail to a test case that is actually exposing the bug is no fun, actually it is because it is challenging and something totally new for me. So after understanding and proposing a solution for this common issue, I have to fix the DumpRenderTool/run-webkit-tests relationship and I can then probably land this fix as well. With it you can go to gmail, browser your mail, see your chat logs but we still have some unimportant issues left like being able to send mails…

So QtWebKit is improving day by day, we mostly implement and fix code in the platform layer, sometimes go to other parts of WebCore and do fixes there.I think it is only a matter of time before we start doing fixes and improvements in the HTML, SVG and rendering implementation.

WebKit is highly addictive, try it out 🙂

PS: I’m going to leave my friends at GMIT at the end of the month, do the math.