- End of contract - closing words.
- Google Code-In 2014 Wrap Up Report
- Contract weekly report #61
- Tracker-Layout has landed!
- Contract weekly report #60
- Contract weekly report #59
- Contract weekly report #58
- Contract weekly report #57
- 'Tis the season for debugging
- Contract weekly report #56 - Media fixes and more!
WebKit weekly report #35
Hello world, another update!
I fixed an important memory leak, so WebKit will now use less memory. Not everything was properly freed when you closed a tab.
I disabled SSE2 instructions (this was already done, but didn't work because one of WebKit build scripts forced them back on). WebPositive can now run on Pentium 2, Pentium 3, and Athlon XP CPUs.
I did some fixes in the interfacing of the BUrl class with WebKit. This improves performance, as URLs can now be passed between BUrl and WebKit without converting them to a string and re-parsing them. It also fixes all the remaining known bugs with URLs.
I added word-wise navigation and selection shortcuts in WebKit. They work just like in BTextView now, and you can use command+left/right to navigate to the next/previous word.
Finally, and perhaps the most important change: Stippi reviewed the HTTP authentication, cookie and cookie jar code and pointed out several problems related to thread safety. I reworked these classes to avoid the issues, so using multiple HTTP connections at the same time, like WebKit does, is a bit more safe. I don't know if all the crashes are fixed, but at least some of them are.
Unfortunately, the next release is still held back because of the drawing optimization problems I mentioned in the previous report. We didn't find a convincing solution to this issue, so I reverted some of the changes to WebKit and I'm now trying to find a solution on that side. This, however, reintroduces some drawing bugs that the slow code had fixed. I will try to find an acceptable compromise here.
Before I close this report, I also wanted to give some news from WebKit. The GTK and EFL ports have stopped supporting the WebKit1 API we are currently using. This is the old single-process version of WebKit. Apple is still using it, because their public API is heavily relying on it, but they strongly suggested we move to WebKit2, the new multi-process API, which is also the one where all the new development is focused. The WebKit1 API isn't going away anytime soon, but it may be a good idea to have a look at WebKit2 and see if we can get it to run on Haiku. However, my main priority currently is getting a stable release of what we currently have, before I start working on new features like this.