WebKit weekly report #21

Blog post by PulkoMandy on Fri, 2014-02-28 07:48

Hello there.

Well, the good news first: for some time I had a bug with GMail, where the top part of the interface (with the search bar, trash button, identity and GMail logo would disappear after the page loaded. This is why I didn't do any release in a while. Well, this bug is now mostly fixed. There is some flickering of the same area, but at least it doesn't completely disappear. I'll be researching the flickering, however it isn't an usability problem anymore, so I can package a release with all the improvements done over the last weeks.

For those interested, the problem was introduced when WebKit made support for "accelerated compositing" mandatory. This used to be an optional feature in WebKit. What it does is rendering parts of the page separately, then mixing (compositing) them together. On other ports, the final compositing step can be hardware accelerated, because it's simple enough (just blending 2D bitmaps over each other, with alpha). For us, the acceleration doesn't exist (we'd need OpenGL or OpenVG or something to make use of the GPU), so this isn't as interesting. However, it's still possible to do the blending in software, which is what WebKit now requires us to do. Anyway, when merging this change, I made a mistake and partially enabled another feature, which we didn't actually implement. This led to some drawing being made off-screen, and never composited in, so it wouldn't be visible. Well, this part is now disabled again, and things seems to work like they did before. We probably still need to implement at least some of the compositing code, but this will come with the transform matrix support, so I'm pushing it to a later time.

Locating this bug wasn't easy, the GMail page is quite complex and not a good place to identify what's triggering the problem. So, I spent most of the week working on the testsuite again. I made some changes to the testsuite engine, for example to dump the scroll position, handle keyboard events (making it possible to test the "editing" features), zooming the page, dumping frame title changes. The testsuite also helped squash some bugs. Synchronous XmlHttpRequests didn't work, because a method override prototype was mismatched (override keyword added, so it won't happen again for this class). Clipping to an empty rectangle would disable all clipping, instead of completely preventing any drawing. Finally, the handling of httpOnly cookies was reversed (they would be visible from javascript, but not from XmlHttpRequests), and Cookies with a max-age didn't properly work if your computer was set for a timezone other than GMT.

With all these small issues fixed, our testsuite results are only slightly better, with 21000 passing tests out of 32000. However, about half of the failing ones are because we don't have a reference of what the test should look like. So, we can easily make those pass by generating a reference rendering. I didn't do this yet, because having a broken reference means the test is "failed" when you finally fix the issue and the (good) result doesn't match the (broken) reference anymore. I'm trying to get all the tests with existing references working first. The remaining issues are a dozen crashes, some of them reproductible, about 1500 tests that time out (either they test some feature we don't implement, or there is some other kind of javascript glitch). The remaining ones are a mix of Js parsing errors (I have no idea how those are passing on other platforms), SVG problems mainly because we don't implement transforms, and some differences in the testing tool (different numbering of frames, for example). And of course, in the middle of this there are some tests failing because of an actual bug in our WebKit port.

I'll continue reviewing these tests. With the GMail bug fixed, I can package a release (expect it today or early next week). I'll then start adding features again. Next up is use of transform matrices to get our SVG drawing in a better shape, Web Notifications (this should be easy and has little potential for causing regressions), and then start looking at HTML5 audio and video (I'm waiting to see if one of our GSoC students wants to handle the media kit side of things for streaming, but I can start working on this with file:// sources). and of course, I expect you to continue opening bugs about non-working websites so I can continue improving the rendering.


Re: WebKit weekly report #21

Great stuff as always Adrien, looking forward to the updated build.

And.... HTML5 audio/video!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! <--- excited for it :)

Re: WebKit weekly report #21

I'm also excited about HTML 5 audio/video.....However, I don't see anything in this update that addresses that. Did I miss something?



Re: WebKit weekly report #21

Out of curiosity, what is the bug in our WebKit port?

Re: WebKit weekly report #21

"and then start looking at HTML5 audio and video"

Last paragraph :)

Edit: ooops... this was supposed to be a reply to Codewrangler.

Re: WebKit weekly report #21

Thanks!... I missed that :-)

Re: WebKit weekly report #21

If you can....go and donate any amount, to keep development going...thanks! :-)

Re: WebKit weekly report #21

hrev46982 x86-gcc2 Web+


QupZilla - OK!

Re: WebKit weekly report #21

Yes, I read your comments on the two previous reports. Could you please stop doing that? It's useless. There are bug reports tracking this issue, and I'll add a notice to one of the reports when it gets fixed. I think this is part of the 'transforms' support I mentionned in this report, and didn't write code for yet.

Re: WebKit weekly report #21

PulkoMandy wrote:

Yes, I read your comments on the two previous reports. Could you please stop doing that? It's useless.
There are bug reports tracking this issue, and I'll add a notice to one of the reports when it gets fixed. I think this is part of the 'transforms' support I mentionned in this report, and didn't write code for yet.

How long will it take to fix this problem?

Re: WebKit weekly report #21

You are doing some amazing work. I'm posting this from the latest nightly and it looks great.

(If only i could read the text i'm typing in this box, it's invisible for some reason!)

Re: WebKit weekly report #21

This bug was fixed shortly after the release, along with a few other important ones (downloads not working, and a few crashes). The bug happens when a box uses both border-radius and a scrollbar, as is the case for this comment form. Since I have also found the cause for the remaining "border bleeding" issues, I'd like to also fix that, and do an 1.2.5 release, which should finally be free of rendering problems! I will also have a look at the issue kim has reported.

Re: WebKit weekly report #21

I think, one should try to with blink instead of webkit.
Opera switched to blink, and even QT switched to blink!
Reading the reasons of qt switching to blink, gives me the impression, that haiku needs to do the same.
Read here for more:

Re: WebKit weekly report #21

Remember that we can't "switch" at will this way. Moving to Blink would mean dropping all the code we have written for WebKit, and starting over. We could try it, but it sounds like a waste of time when we already have a working browser.

There are some other reasons for not going with Blink. While it has a better platform abstraction model, this also means it is hardwired to some libraries: there is only one network backend, and one rendering engine. No way to use the native BView drawing, no way to use the Services Kit. While this is probably fine on the network side, I think it is important to use BView drawing code, because it gets us a native look to the browser. Using the same font rendering, and the same antialiasing code, means the rendered HTML just fits better with the way other parts of the system look.

I'll add that WebKit isn't going to die: it has support from Apple, Samsung and Intel (through the EFL and Tizen projects), and GTK, and there are quite a few other ports out there, even if they are not merged into the main development trunk. This includes Haiku, but also Blackberry, and a few others. I'll add that interesting changes from Blink are often merged back to WebKit.

I don't agree with the Qt people on the portability of WebKit. There are a lot of ports to very different platforms, much more than on the Blink side, as far as I can tell. In WebKit, the ability to disable features we don't support allowed us to get a browser running, and then gradually add those features as we implemented them. I don't believe such a thing is possible with Blink, where the approach is more all-or-nothing.

That being said, I have nothing again someone starting a Blink port and trying to get Chromium running on Haiku. Competition is good!

Re: WebKit weekly report #21

I guess, it's better to throw now work away, then throwing later much more work and money.
In general, google has great developers, they are all the time popping up with new idea, and chrome is great to use (and will be even better when portable native client will be in a better shape).

I think, if we go with blink, we have a little chance, that google will one day put more money in haiku, or support it, or google devs helping out porting chrome to haiku. I don't know how "native" chrome is on windows or linux, but if it would be as native on haiku, as it is on linux or windows or OSX , it would be a big win.
Chrome is a big success, and I guess for many it's a little frustration not having it.
If I had to bet, which ones survives longer, then I would bet on google. I has in general better programmers, is more innovative and is a bigger supporter of open-source (e.g. gsoc).

I understand that it is not an option, to throw away webkit, but perhaps one should start in parallel, also some work on blink, to make it build, since it has the better chances of success compared to webkit. The fact that QT switched to blink, and will improve the webkit support anymore, is a clear sign. (I think, I even read, that chrome is going to be the standard browser on android). The chromebooks, are also expected to gain more success.

Re: WebKit weekly report #21

On the WebKit side we still have Apple (with Safari for iOS and Mac OS X), Samsung and Intel (with Tizen and EFL), RIM (with Blackberry), and GTK (with GTKWebKit, used by many GTK applications including the Midori browser). I don't think the project is going to die anytime soon. There are also other developers maintaining their own version of it (for embedded devices or the like).

Both Apple and Intel also have a long history of open sourcing their work now. Think about Darwin, the Intel graphics card drivers, etc. I think they are on the same range as Google on this. You can check Intel's open source page: https://01.org/ , and Apple's one, which is small, but has sources for a lot of their system's components (even if not everything): http://opensource.apple.com/. They both have engineers probably as good as Google one (why would that not be the case?). I don't know about Samsung and the other WebKit developers, but things are probably similar for them. If you don't know about it yet, have a look at Tizen. This is a Linux Foundation project to... replace Android. No less. They have full support from Samsung and Intel, both of which are not too happy with Android and Google taking most of the mobile phone and tablet OS market. While there are no devices shipping with Tizen yet, this should change during this year, and who knows what the future is made of?

As I said, I would also love to see someone start porting Blink, so we can get Chrome and/or Opera ported. But, this is probably a lot of work, without visible results for a long time. And we can't really say that WebKit isn't working for us, so far it's been going very well.