WebKit weekly report #44

Blog post by PulkoMandy on Fri, 2014-09-12 07:26

Hello there!

Yesterday I released version 1.4.4 of HaikuWebKit. This version includes the latest fixes to the rendering code and should be completely useable again. There are still a few drawing issues but they shouldn't prevent you to browse the web anymore.

This is not the only change in this release. I ran through the html5test.com results and implemented some of the missing features to improve our score. The most visible changes are:

  • Input type="color" is now implemented, with a pop-up color picker
  • The css :read-write selector is implemented (not my work, this was done by the Apple guys)
  • Web Notifications are supported, using our notification server
  • The download attribute on hyperlinks is supported. This can be used to force a link to be downloaded, rather than shown in the browser.

I worked on some other features, but the implementation is not working well enough so I skipped them for this release. I will resume work on those and try to get them working properly, but for now it's better to leave them disabled and let websites fall back to non-HTML5 alternatives.

  • input type="date" and related (time, week, month, ...) are not rendering properly
  • Geolocation can be enabled, but we need some data to return. It seems Firefox is using some Google service to guess a location from your IP address and wifi network your computer can see. This will be optional, and user will be prompted before such sensitive information is sent to a website.
  • Device orientation can also be enabled, but we usually don't have accelerometer data to report. I don't know what other desktop browsers are using here.
  • Web Crypto and CSP 1.1 don't seem to work even after enabling support in WebKit. I haven't found if this is a problem of missing something in our code, or just incomplete implementations on WebKit side.

With all these features enabled, we will get more than 400 points on the html5test. I will first try to get the more interesting features working (the date and time inputs in forms). Things like Web Crypto and CSP 1.1 are still drafts at the W3C, so it's better to wait until the specifications are frozen and the WebKit implementation is done.

The html5test goes up to 555 points. The remaining 155 are things like speech synthesis, video DRM support, and some other less useful things. I'm not sure they are worth my time. One of the features I may still look at is WebGL, but without OpenGL acceleration this is rather useless.

My plan for next week is to take a break from the WebKit coding and migrate Haiku to Python 2.7. We are using 2.6.9 but WebKit will require 2.7 starting next week, so it's time we update this. Then I will get back to those HTML5 features and the remaining drawing issues.

Comments

Re: WebKit weekly report #44

Quote:
Device orientation can also be enabled, but we usually don't have accelerometer data to report. I don't know what other desktop browsers are using here.

I think it is safe to say that this will be handled in the app_server, ie. an application will always have 0,0 in the upper left corner of the screen.

IOW you can just do a width > height comparison to find out about the screen orientation.

Re: WebKit weekly report #44

You can't just do a width x height comparison as putting an LCD in portrait mode would not work... and it is acutally quite handy since most documents/code etc are longer than they are wide.

Re: WebKit weekly report #44

I don't understand what you are trying to say. If we allow to rotate the screen (we don't do that yet), width x height will change, so you always know the screen orientation from within the application.

Re: WebKit weekly report #44

I think I follow you. So the app server should always just know what orientation the screen is in and map 0,0 to the right place... and Web+ can just deduce the layout from the with x height since those will also change if the screen is rotated.... I must have been tired when I read your comment earlier becuase I didn't brain it very well ;-)

Re: WebKit weekly report #44

Well done Oliver, that is really useful work!

I experienced some kind of hang though, I will see if I can reproduce it for you to look.

Re: WebKit weekly report #44

His name is Adrien ;-)

Re: WebKit weekly report #44

Yes! Sorry I can't correct my mistake. Thanks Adrien.

Re: WebKit weekly report #44

The "device orientation" API is not about just portrait/landscape. It's about providing the accelerometer and MEMS values (acceleration, orientation vs. magnetic north pole) to HTML5 webapps. Nothing app_server should be involved with. Maybe input_server, but we still need drivers and relevant hardware.

Re: WebKit weekly report #44

Well, at least you know what you can return about the actual orientation; after all, that should be the most useful information for a web browser.