linux.conf.au browser miniconf 2013

Schedule

Below is the schedule for the Browser Miniconf on Tuesday, 29 January 2013.

Implementing Threaded Accelerated Compositing in WebKit GTK+

Gwang Yoon Hwang · Slides

The main thread is where everything gets executed including layout and scripting. Thus, running compositing in the main thread severely limits responsiveness and rendering speed. By having a separate thread for compositing, we can bring a significant performance improvement in scrolling, zooming, and rendering, especially CSS3 animations.

Currently, several ports have already implemented off­the­main thread compositing. Coordinated Graphics System, which is used by Qt and EFL, runs accelerated compositing in the UI Process. Compositor Thread used by Google Chrome runs the compositing thread off the main render thread in the Renderer Process.

Our Threaded Compositor is another accelerated compositing implementation, which is a threaded variant of Coordinated Graphics System. We are currently contributing Threaded Compositor to WebKit GTK+. Threaded Compositor makes WebKit GTK+ render CSS3 animations faster. Threaded Compositor brings a few benefits compared to the current Coordinated Graphics System. Firstly, by performing accelerated compositing in the Web Process, the UI process is isolated from the crashes caused by GPU driver bugs. Secondly, by not performing accelerated compositing in the main thread of the UI process, the UI process becomes more responsive to UI events.

In this talk, we will cover how we brought this feature to WebKit GTK+, and its current status. Additionally, optimized features for embedded systems such as memory management will be discussed.

Gwang Yoon is a software engineer at Company 100, working on GPU acceleration for WebKit in embedded systems. He is interested in the WebKit rendering system, especially accelerated compositing and accelerated 2D vector graphics on embedded GPUs.

Panel session

Jeremy Apthorp, Cameron McCormack, Silvia Pfeiffer, Shane Stephens, Dirk Schulze, Ben Kero

Join our panel for a discussion of topical topics related to Web browser development, authoring, standardisation, and other issues related to the Open Web Platform.

Defeating Cross-Site Scripting attacks with Content Security Policy

François Marier · Slides

Cross-site scripting vulnerabilities are very common in web applications. They have been in the OWASP Top 10 for a while and are routinely used by attackers.

There are simple guidelines that one can follow to prevent XSS bugs and most of the web frameworks out there offer some level of protection but at the end of the day, it's easy to make a mistake.

Content Security Policy adds another layer to a website's defenses: browser-enforced restrictions against external resources or unauthorized scripting. An extra response header instructs browsers to enforce a policy set by the server administrator.

François is a software engineer on the Mozilla Identity team where he works on Persona, the new decentralized authentication system for the open web. A long time Debian developer, Francois has been involved in Open Source and web development for a while and has always had a strong interest in security.

The WebKit Browser Engine – An Overview

Dirk Schulze

WebKit is an open source project, based on KHTML, KJS and KSVG2 from the KDE project. It is the default browser engine of Safari, Chrome and a lot of mobile and embedded devices and frameworks like mobile phones, tablets, eBook readers or TV but also Qt and other libraries.

WebKit is not just one browser engine. In fact, it consist of different so called ports. Currently WebKit has at least seven maintained WebKit ports in the project repository. To organize all these ports, different abstraction layers are needed. The overall three layers are WebCore, JavaScriptCore(/V8) and "WebKit" (the platform integration level).

WebCore is the abstraction layer that is responsible for parsing, rendering and painting a web document. During the parsing of an XML, MathML, SVG and HTML document, the so called DOMTree and RenderTree is build. The DOMTree is a hierarchy of DOM elements representing the document. A RenderTree is a rendering/painting hierarchy of the elements. The RenderTree consists of so called RenderObjects. Each of the RenderObjects represent (mostly) a graphical element with all necessary information to layout/render and paint an element on the screen.

Dirk is a web developer, browser implementor, and specification editor. He joined Adobe in 2011. Prior to that, he worked at RIM. As an active member of the W3C and the Khronos Group, he contributes to various specifications like CSS3 Transforms, Filter Effects, SVG2, CSS Masking and WebCL. Furthermore, he has been a reviewer and contributor to the WebKit project for over 5 years. He belong to the Canvas, SVG, and Filter Effects implementation teams in WebKit.

Web IDL: Defining Web APIs and Implementing JavaScript Bindings

Cameron McCormack · Slides

The interface for modern Web APIs are defined using a language called Web IDL, which is a language similar to OMG IDL that is geared towards defining interfaces to be used from JavaScript, while still providing some degree of language independence. Web IDL includes very strict requirements on how DOM objects are exposed to JavaScript, and by this promotes compatibility across different browser implementations.

In this talk, I will describe the history of language bindings in Web standards, and show some examples of Web APIs defined using Web IDL and how they are exposed to JavaScript. Finally, I will discuss how Mozilla is using interfaces defined in Web IDL directly as a basis for generating our C++–to–JavaScript binding code.

Cameron is a software engineer at Mozilla where he works mainly on Gecko's SVG and CSS internals. He is the editor of the Web IDL specification at the W3C Web Applications Working Group and also co-chairs the SVG Working Group.

Web Animations: unifying CSS Transitions, CSS Animations, and SVG

Shane Stephens · Slides

The Web Animations specification is a new effort to unify CSS and SVG animations into a single animations engine. This engine will act as a future expansion point for new animations primitives. I will introduce the specification, talk about some of the justifications for it, and demo the API via a polyfill.

Shane is a Software Engineer at Google, and a member of the Chrome team, working on WebKit’s implementation of CSS. Shane has been involved with the open source community since university. Shane's previous FLOSS-related projects have included liboggplay, which is a library for synchronized playback of ogg media; the Annodex Firefox plugin; and the Google Wave project as part of the API team.

The Horrible History of Web Development

Daniel Nadasi · Slides

We live in a golden age, one where I, as a web developer, can implement something developing in one browser and can be somewhat confident that something remotely consistent will appear in the recent versions of most other major browsers. It's not perfect, but it's heaven compared to where we were. But it took us a long time to get here.

In this talk, Daniel will give a brief but colorful history of how web developers have experienced the browser wars. Broken standards, seemingly arbitrary per-browser APIs and non-existent deprecation timelines have caused web developers to tear their hair out for more than a decade. It's all funny in hindsight…

Daniel Nadasi is a Software Engineer at Google. He currently works on helping chain businesses get their presence onto Google Maps and Ads, having also worked on Google Tasks and Open Sourcing Google's code. He's suffered far too much at the hands of web browsers, and now he's back for revenge.

The Future of HTML5 Apps

Jeremy Apthorp

HTML has long been one of the best tools available for building rich and beautiful interfaces. But for the most part, developers building desktop and mobile apps have been stuck with more traditional UI toolkits such as Cocoa and Android in order to get access to the rich feature set that native apps permit. This talk will cover some of the historical attempts to have our cake and eat it too, and what we're doing in Chrome and with standards groups to try to bring this dream to reality.

Jeremy has been a long-time fan of HTML and JavaScript (though given a choice, he prefers CoffeeScript), and enjoys writing games and bending the laws of physics. He has been working at Google for the past year and a half, on the Chrome team in Sydney.

• View
• Edit
• History
• Print