- Debugger: Getting mixed signals
- 'Packaging Infrastructure' Contract Weekly Report #4
- Haiku monthly activity report - 06/2015
- 'Packaging Infrastructure' Contract Weekly Report #3
- 'Packaging Infrastructure' Contract Weekly Report #2
- GCI 2014 winners trip report (mentor side)
- TeX Live and LyX; Changes to the boot code
- 'Packaging Infrastructure' Contract Weekly Report #1
- Beginning of 'Packaging Infrastructure' Contract
- Haiku monthly activity report - 05/2015
WebKit weekly report #15
Hello again!
No big new changes this week, but a lot of small fixes and improvements.
I reviewed the growing issues list for Web+ on the bug tracker, and fixed several of them. Most of these were small and rather easy to fix bugs (I kept all the harder ones for later). Here is a list with comments, not that the issues were hard to track, but this is also a way to learn a bit more about the WebKit codebase.
Web+ crashed when trying to upload a file to GMail. This was a bug in our BFormDataIO code we use for serializing the form data into the HTTP stream. It missed the case where the first element in the form was a file, and tried to read from it without initializing it first. The FormDataIO class is used so we don't have to put the whole form data in memory in order to send it. It handles each form element one at a time, with special case for files, which are streamed from disk in small chunks, rather than loaded into memory.
Web+ also crashed when trying to decode a huge image. The test case for this is a 93MB JPEG file that expands to 700+MB of pixel data. ShowImage manages to display that, however Web+ tries to do incremental decoding, showing an incomplete view of the image as it is loaded. Our implementation of this is not optimal, as there are at least two copies of the data, one in a BBitmap and one as a raw byte array. For now I fixed the crash, but we abort the decoding and just show a blank page instead. We may want to review the image code to lower the memory use.
I implemented listing local directories in the Services Kit. WebKit has support for rendering directories as part of their FTP handling. Returning files list in one of the formats FTP listings use (there is no standard for this, but a few common formats in use) makes WebKit parse it and generate an HTML page for listing. There are still some problems with encoding (WebKit doesn't seem to expect UTF-8 filenames in those listings), but things should be working now. I also fixed some problems with symlinks in the file:// protocol handler.
Some drawing glitches were fixed (again). We're now in a state where all improvements will require adding support to BView.
There was also a problem with opening links in a new tab from inside a frame. I also added shift+middle click as a way to open a link in a new tab and immediately switch to it (middle click alone opens the tab in the background).
I did several fixes to Cookie management. The most important one is there was a bug in the code for getting cookies for a specific website. A misuse of our StringHash class (this is a simple class that allows using a string as a hash for a hash map) led to memory corruption. We were trying to set the key for the map to a substring of the previous key to implement domain exploration (so a site at www.example.com can access cookies set at example.com - but not for just 'com'). Basically, the HashString freed the old key, then tried to copy characters from it to the new key, using memcpy. This is a classic use-after-free problem, that didn't always create problems in normal run, but was very obvious when running the browser with libroot_debug. Another fix was the proper implementation of CookiesForDOM. This is one of the two methods for accessing cookies. We used the same code as for the access from Javascript, but CookiesForDOM must also include "HttpOnly" cookies. Finally, a third bug was wrongly parsing the expiration date for cookies using the local time zone, whereas they need GMT dates. Depending on your timezone, this lead to cookies expiring too late (you probably didn't notice) or too early, sometimes right in the past. For example, some banking website use short-lived cookies (1 hour or less) as a timeout system. In my GMT+1 timezone, the cookie was expired immediately and I couldn't even access the login screen.
Some fixes went into the SSL support. One case of crashing was fixed, we were deleting the OpenSSL connection context before the network thread had a chance to exit, leading to a crash when leaving an https page before it finished loading. I also started work towards proper support for certificate checking. SSL connections didn't do any checking for certificates, and actually didn't even load the certificate store, making the SSL host authentication useless (you still get the encryption, but you can't make sure you're sending things to the right server). I implemented the Network Kit side of things, but now I must get this exposed in the Services Kit, then in WebKit, and finally add a nice dialog in Web+ asking what to do. Then, I must get the answer back to the network kit and continue or stop the connection with the unsafe host.
On WebKit side, I did a lot of small - but useful! - usability enhancements.
We got the error reporting for non-http connections working again. When trying to open a non-existing file:// URL, you now get a "file not found" message instead of a blank page.
The URL bar now always has an icon (the default is a little globe), to avoid the URL jumping to the right when the favicon gets shown. I also fixed some glitch pixels below the text in that bar, when using small font sizes.
I reworked some of the bookmark loading code. Now, bookmarks load in the current window, instead of the first window they can find in the workspace. If you open several of them at the same time, it works as expected. There was a race condition leading Web+ to try opening several bookmarks in the same tab, with of course only the last one showing up. Another problem was it was not possible to use symlinks in the bookmarks folder, as the BNavMenu we use for bookmarks wasn't traversing them. This now works as expected.
The search page in Web+ is now configurable. This means you can switch to goodsearch.com and help raise some money for Haiku while searching! Or, you can use the local version of Google or whatever search engine you prefer. The bug that made us unable to search for UTF-8 strings was also fixed, so you don't have to search in english anymore. And, there was also some progress with IDN domains, but the complete fix for this will have to wait for the next update to the WebKit package.
So, what's next? I will continue working on better SSL support, as this is currently set as an alpha blocker. I also plan to have a look at doing a bookmark bar. I tried doing this as a BMenuBar + BNavMenu, but these classes aren't designed for multiple inheritance, so I have some refactoring to do there. Or maybe I should go with another approach.
The "network lock-up" bug and missing BView features are also still fairly high on the TODO list, but these will need more time as I'm not as familiar with the code in these areas.
I didn't do this for some time, but let's also talk about non-working-hours time I also spent on Haiku. I did some Haikuporter recipes for XRick, OpenTTD, and a few other games. I also finally made a recipe for libusb, and others have used this to compile libftdi and avrdude. This isn't quite working yet, but I hope someone gets it going so I can finally do some hardware hacking on Haiku (did I hear blinkenlights?).
See you next week!
- PulkoMandy's blog
- Login or register to post comments

Comments
Re: WebKit weekly report #15
Great stuff as usual Adrien, always look forward to your updates.
Been meaning to ask you, what are your thoughts on Blink? Seems one of the goals is better "multi-platform" support, irrc.
Re: WebKit weekly report #15
Well, the multiplatformness in Blink has some good and some bad sides.
WebKit is done in a way that requires a lot of work to port. We provide our own network backend, our own drawing code, and we will provide our own media code for and support. This is some extra works for us, but it means the port is actually native: it uses the same network code as other Haiku apps, the same font rendering and drawing algorithms, and the same video codecs. This makes WebKit at least feel native.
We could have gone with porting WebKit using existing libraries (soup for network, gstreamer for video, and cairo for graphics). This is a bit similar to what Blink is doing: they pick a set of libraries and require you to port that. This may result in easier porting, but there are two main reasons for me not doing it: I don't think we can get the same native feel the WebKit port has, and, we already did all that work (or most of it) for WebKit. There are some things missing, but adding them to Haiku will allow other applications to make use of them (the streaming support in media kit has obvious applications in DVD playing, webradios, and more ; the extended BView APIs certainly will find some use as well, and the HTTP support in Network Kit is already useful for fRiSS, and I hope to see other apps joining).
I think WebKit is a good way because it allows us to get both a better web browser, and a better Haiku for native apps. And while a good web browser is important, we don't want Haiku to turn into a ChromeOS/FirefoxOS clone, do we?
Re: WebKit weekly report #15
Thanks for the reply Adrien, makes sense :)
Re: WebKit weekly report #15
the streaming support in media kit has obvious applications in DVD playing,
So have you thought about implement streaming in the media kit? ;)
oh and relay greate work you are polling off :)
Re: WebKit weekly report #15
The most important thing right now is fixing the remaining drawing glitches, so this week I'm working on the app_server stuff. I think media kit streaming comes next, unless I find something more important to fix.
Re: WebKit weekly report #15
Nice :)
Oh and I noticed that when I logon to my mail (wm.crystone.net) The browser chrashes. I havn't reported it in track but I will :). Do you need that dump file aslo?
Re: WebKit weekly report #15
Sounds great!
BTW is this part of the latest nightly download? I'm never sure when these changes are actually part of the tree or just done on your system. People have told me to watch the source activity but I'm not sure the exact phrasing you'd use etc. and there's a lot of source activity, plus it doesn't seem to have the person's name when I click to view more, or even sort it chronologically if I search. Am I missing the easy way? Or if you blog about it it's in the nightly tree already? Just want to figure out an easy way to know when something's available to try out. :)
Thanks,
Kev
Re: WebKit weekly report #15
The easiest way is to filter by path. Looking here you can see the last time I merged HaikuWebkit packages:
http://cgit.haiku-os.org/haiku/log/build/jam/repositories/HaikuPorts/x86...
Last time was on 11 december, so not all the things I did this week are in yet. The changes that happened on Haiku side are, however. You can see most of them looking at these places:
http://cgit.haiku-os.org/haiku/log/src/kits/network/libnetapi
http://cgit.haiku-os.org/haiku/log/src/apps/webpositive
You can also watch the tickets: http://dev.haiku-os.org/query?component=%5EApplications%2FWebPositive&co... (there are RSS feeds for this).
Re: WebKit weekly report #15
The easiest way is to filter by path. Looking here you can see the last time I merged HaikuWebkit packages:
http://cgit.haiku-os.org/haiku/log/build/jam/repositories/HaikuPorts/x86...
Last time was on 11 december, so not all the things I did this week are in yet.
Thanks for the links, but I'm still a bit confused. When I follow that 1st one I see the dec 11 merge, but then I also see one on Jan 6 and two on Jan 13. How does one distinguish between updates that mean something has changed and updates that don't? :)
Thanks,
Kev
Re: WebKit weekly report #15
Look at the ones for HaikuWebkit, like this on 11 december:
The other changes are to other packages (gcc and Vision).
Re: WebKit weekly report #15
Look at the ones for HaikuWebkit, like this on 11 december:
The other changes are to other packages (gcc and Vision).
I'm not sure where you get 11 december on that one. "8 days" before you posted was Jan 13, which is what you get when you click that item. Version 1.2.1, OTOH, was from 11 december. That's why I'm confused...
Re: WebKit weekly report #15
Between OpenTTD and Webkit, Haiku is getting close to having all I need in an OS now :-)
Re: WebKit weekly report #15
do you mind sharing the patch+recipe for libusb?
Re: WebKit weekly report #15
The libusb recipe is on haikuports. The code is on my github account.
Re: WebKit weekly report #15
thanks alot