Page Cache vs. Disk Cache vs. Memory Cache in Browser

  1. Page Cache
    1. 웹페이지에서 사용자가 다른 링크를 클릭해서 다른 페이지로 넘어 갈 경우, 현재 페이지의 DOM tree, image resource, JavaScript object, Plug-in등을 다 clean up을 하는게 맞으나, 사용자는 대게 현재 페이지로 다시 돌아올려고 하는 빈도가 많은데 이렇게 현재 페이지의 리소스들을 다 없애 버리면 사용자가 back 했을 경우, 다시 처음부터 html, resource 다운로드 받고, parsing하고 이미지 decoding, layout, re-scroll등의 작업들을 다시 하여야 한다.
      이러한 오버헤드를 막기 위해서 Page Cache 라는 개념을 도입하여서, 사용자가 다른 페이지로 navigate할 때, 현재 페이지는 메모리에 suspend되고 사용자가 다시 돌아왔을 경우에 이를 다시 resume함으로서 smooth한 사용자 경험을 제공할 수 있다.
  2. Memory Cache
    1. Web page의 sub resource(이미지, 스크립트, 스타일쉬트 등)를 메모리에 저장하여, loader에서 web page를 로드 할 때, 여전히 사용되는 Resource들은 web server에서 받아오지 않고 메모리에 cache된 것을 사용한다.
  3. Disk Cache
Advertisements

WebKit EFL 포트

오늘 소개할 내용은 WebKit EFL 포트입니다. 우선 WebKit에 대해서 간략히 소개드리면, WebKit은 Apple이 주도하고 있는 오픈소스 Web Rendering Library로서 2005년부터 오픈소스 프로젝트로 전환된 후에 현재 Apple Safari 브라우저, 아마존 킨들, WebOS, Epiphany 브라우저, 그리고 2013년 4월까지 Chromium의 렌더링 엔진으로 사용되어져 왔습니다.

60px-Epiphany-web-browserAmazon_Kindle_logo.svg

Apple_SafariLG_WebOS_New.svg

그 중 WebKit EFL 포트는 삼성이 Tizen 플랫폼의 Web Rendering 엔진으로 사용하기 위해서 2010년부터 WebKit 오픈소스 프로젝트에 추가한 포트입니다. EFL은 GTK, QT등과 유사한 UI Toolkit 으로서 Tizen의 UI Framework으로 사용이 됩니다. 이에 EFL UI Framework과 연동해서 동작하는 Web Rendering 엔진이 필요하게 되었으며, 이를 위해서 WebKit EFL포트를 추가한 것입니다.

Tizen_logo_and_wordmark

2014년 12월 현재 WebKit에 official 하게 관리되고 있는 포트는 아래 buildbot에서 보는 것과 같이 WebKit Mac, GTK, 그리고 EFL 포트 뿐입니다. Chromium이 WebKit을 포킹해서 Blink라는 새로운 프로젝트로 떠난 후, WebKit QT, Blackberry포트 등도 같이 떠나던가 drop이 되었습니다.

아래는 현재 WebKit mainline에서 운영되고 있는 Mac, GTK, 그리고 EFL 포트의 buildbot의 waterfall 입니다.

buildbot

현재 EFL 포트는 WebKit2 EFL Release 빌드와ARMv7 Thumb2 / Traditional, 그리고 Performance bot을 운영 중입니다.

efl-buildbot

아래의 WebKit EFL Overall Architecture에서 보시는 것처럼 Tizen Native Platform 을 기반으로 Web 에서 필요한 Rendering, Multimedia, 그외 Device API등을 지원하기 위해서 WebKit에서 Tizen의 Native Resource들을 사용 하고, Browser라던지 Web Runtime과 같은 WebView를 필요로 하는 Application들에게 WebView API를 제공해 주어 다양한 어플리케이션에서 Web 기반의 기능을 제공해 주고 있습니다.

webkit-arch

현재 WebKit EFL 포트는 Tizen 플랫폼의 Web Rendering 엔진으로 그동안 삼성 NX300 시리즈, NX1등의 카메라와 기어 2, 기어 S등의 웨어러블 기기에 탑재되어 상품화가 되었습니다. 향후 더 많은 Tizen 기반 디바이스에 탑재되길 기대해 봅니다 !

nx300m

nx1

gear2

gears

아래 부터는 어떻게 WebKit 소스코드를 받고, WebKit EFL 포트를 빌드 하는지에 대한 방법입니다.

1. WebKit 소스 코드 다운로드
$> git clone git://git.webkit.org/WebKit.git WebKit

2. WebKit EFL 포트 빌드
$> cd WebKit
$> Tools/Script/build-webkit –efl (–update-efl)
(첫 빌드시에는 반드시 –update-efl 옵션을 붙여서 빌드를 해주어야 합니다.)

3. EFL MiniBrowser 실행
 $> WebKitBuild/Release/bin/MiniBrowser

4. EFL Layout Test 실행
$> ./Tools/Scripts/run-webkit-tests –efl –release –no-show-results  \
–results-directory layout-test-results –exit-after-n-failures 500 –verbose -2

만약 빌드 혹은 런타임시에 문제가 있다면, irc.freenode.net 에서 #webkit-efl 채널에 오셔서 문의를 해주시거나 혹은 아래 WebKit EFL 메일링 리스트에 가입하신후 문의해 주시면 됩니다.

https://lists.webkit.org/mailman/listinfo/webkit-efl

How Browsers Work: Behind the scenes of modern web browsers – Korean Translation Ver.

Browser Main Components

User interface  :  일반적으로 User Interface는 address bar, back/forward button, bookmark menu 등을 말합니다. 다시 말해서 사용자가 요청한 페이지가 그려지는 main window를 제외한 모든 부분을 일컫습니다.

Browser engine :  User Interface 와 rendering engine 사이의  action을 통제하는 엔진으로서 WebKit 에서는 포트 레이어가 해당됩니다.

Rendering engine : content 를 화면에 그리는 역할을 합니다. 예를들어, HTML과 CSS  content를 parsing하고  그것을 화면에 그립니다..

Networking : Server로 부터 data를 가져 오기 위한 http request를 처리하는 레이어입니다. WebKit에서는 각 포트별로 Network Library를 가지고 지원을 하고 있습니다..

UI Backend : combobox, listbox 등과 같은 widget을 그려지는 모듈. 일반적으로 플랫폼의 UI widget interface를 사용해서 그립니다.

JavaScript Interpreter : JavaScript를 parsing하고 수행합니다. WebKit의 경우는 Squalfish Extream이라는 엔진을 통해서 bytecode를 바로 native code로 변환해서 처리합니다.

Data storage : 한마디로 cookie 와 같은 정보를 HDD에 저장하기 위한 database 입니다. HTML5 에서는 web database를 정의했으면 이것은 거의 완벽한 database 입니다.  WebKit에서는 sqlite light를 이용해서 이 기능을 지원합니다.

layers

Rendering Engine

대표적인 Rendering Engine으로는 Firefox의 Gecko엔진과 Safari와 Chrome이 사용하고 있는 WebKit이 있습니다. WebKit 은 리눅스 플랫폼에서 시작된 오픈소스 렌더링 엔진이면서 애플을 통해서 맥과 윈도우에서 동작을 하고 있습니다. 현재는 Google Chrome, GTK, QT 그리고 EFL을 통해서 다양한 플랫폼과 UI Framework위에서 동작을 하고 있습니다.

The Main Flow

Rendering 엔진은 Networking 레이어로 부터 요청한 문서를 얻기 시작합니다. 일반적으로 브라우저는 8 KB 씩 컨텐츠를 받습니다. 아래 그림은 8K의 Content를 받은 후의 Rendering 엔진의 기본 흐름을 보여주고 있습니다.

flow.png.pagespeed.ce.pK__f2HjCm

Basic Flow

Rendering 엔진은 HTML 문서를 파싱하기 시작하고 “content tree”라고 불리우는 DOM Tree에 각 node를 생성합니다. 또한, inline과 external CSS  파일도 파싱하기 시작합니다. 그리고, 여기서 처리된 style 정보는 HTML의 visual 정보와 함께 나중에 보게 될 render tree를 생성하는데 같이 사용 됩니다.

Render tree는 색상과 크기 정보를 가진 사각영역의 정보를 기본으로 생성이 됩니다. 그리고, render tree가 생성이 되면 이 render tree는 layout 이라고 불리는 단계를 거치게 됩니다. Layout 단계는 render tree의 각 노드가 화면에 보여질 좌표를 계산합니다.

Layout 단계 이후에 마지막으로 painting이란 단계를 거치게 되는데 이 단계에서는 layout 단계에서 처리된 render tree의 각 노드를 탐색하면서 화면에 그리는 역할을 하게 됩니다. 이러한 기본 단계를 통해서 브라우저는 웹 문서를 화면에 보여주게 됩니다. 이렇게 점진적으로 웹문서를 화면에 보여주는 이유는 브라우저는 가능한 빨리 웹문서를 사용자에게 보여주는것을 목표로 하고 있기 때문입니다. 즉, 모든 웹문서를 받은 후에 그것을 한번에 화면에 그리는 것보다 점진적으로 보여주는 것을 사용자가 더 선호하기 때문입니다.

webkitflow.png.pagespeed.ce.KhQEkvbb3q

Figure 3: webkit main flow

webkitflow.png.pagespeed.ce.KhQEkvbb3q (1)

Figure 4: Mozilla’s Gecko rendering engine main flow

Gecko 는 element 트리를 “Frame Tree”라고 부르며, 각 element는 frame 이라고 부릅니다. 반면에 WebKit은 element 트리를 render tree 라고 부르며 각 노드는 Render Object라고 부릅니다.

Parsing – General

Parsing은 rendering 엔진에서 아주 중요한 단계이기 때문에, 우리는 조금 더 깊이 이 부분을 보겠습니다. 우선 parsing에 관한 간략한 소개를 시작해 보겠습니다.

하나의 문서를 Parsing 한다는 것은 문서를 특정 코드가 이해하고 사용할 수 있는 논리적인 구조로 변환 하는 것을 말합니다.  Parsing의 결과는 대게 문서의 구조를 표현하는 node의 tree 입니다. 일반적으로 parse tree 또는 syntax tree라고 합니다.

예제 – “2 + 3 – 1” parsing하면 아래와 같은 tree를 얻게 됩니다.

figure5

Grammars

Parsing 은 문서가 따르고 있는 언어의 포맷에 기반한 구문(syntax)  규칙에 기반해서 이루어지게 됩니다. 브라우저가 parsing 할 수 있는 모든 포맷은 단어와 구문 규칙으로 이루어진 결정론적(?) 문법을 가지고 있습니다. 보통 이러한 문법은 context free grammar라고 불립니다. 인간의 언어는 그러한 언어가 아니기 때문에 관습적인 parsing으로는 parsing 될 수가 없습니다.

Parser – Lexer combination

Parsing 은  lexical 분석 단계와 syntax  분석의 두개의 하위 단계로 나뉠 수가 있습니다.

Lexical 분석은 입력된 데이터를 token들로 쪼개는 단계입니다. 여기서 말하는 token은 의미를 가진 언어 단위라고 이해하면 될 것 같습니다. 사람의 언어로 예를 들자면, token은 언어 사전에 나오는 단어들이라고 생각하면 되겠습니다.

구문 분석은 언어의 구분 규칙을 적용하는 단계라고 보면 됩니다.

보통 Parser는 일을 두개의 component로 나뉘는데,  그 단계는 입력된 값을 의미있는 token들로 구분해 주는 lexer(때때로 tokenizer로 불립니다.)와 언어 구문 규칙에 따른 문서 구조를 분석을 통해서 Parse Tree를 생성하는 parser로 이루워져 있습니다.  Lexer는 공백이나 줄바꿈과 같은 의미없는 input 값들을 제거합니다.

figure6

Parsing은 반복적인 과정입니다. Parser는 Lexer에서 새로운 토큰을 요청한 후, 토큰을 구문 규칙과 비교를 합니다. 만약 토큰에 해당하는 구문 규칙이 있다면, 그에 해당하는 Node가 parse tree에 더해지고, Parser는 다시 Lexer에게 새로운 토큰을 요청합니다. 그러나 만약 토큰에 해당되는 구문 규칙이 없다면, Parser는 내부적으로 토큰을 저장해 놓은 후, 저장된 토큰에 해당하는 구문규칙을 모두 검색을 합니다. 그러나, 만약 해당하는 규칙을 찾지 못한다면, Parser는 예외를 발생시킵니다. 이것은 웹 문서가 유효하지 않은 구문을 가지고 있다는 것이고 구문 에러를 가지고 있다는 것을 말합니다.

Translation

Many times the parse tree is not the final product. Parsing is often used in translation – transforming the input document to another format. An example is compilation. The compiler that compiles a source code into machine code first parses it into a parse tree and then translates the tree into a machine code document.

figure7

Parsing example

Figure 6에서 우리는 수학적 표현으로부터 Parse Tree를 생성했었다. 그럼 이제 하나의 단순한 수학적 언어를 정의하고 그것의 parsing 과정을 한번 보도록 하자.

Vocabulary: Our language can include integers, plus signs and minus signs.

Syntax:

  1. The language syntax building blocks are expressions, terms and operations.
  2. Our language can include any number of expressions.
  3. An expression is defined as a “term” followed by an “operation” followed by another term
  4. An operation is a plus token or a minus token
  5. A term is an integer token or an expression

Let’s analyze the input 2 + 3 – 1.
The first substring that matches a rule is 2, according to rule #5 it is a term. The second match is 2 + 3 this matches the third rule – a term followed by an operation followed by another term. The next match will only be hit at the end of the input. 2 + 3 – 1 is an expression because we already know that 2+3 is a term so we have a term followed by an operation followed by another term. 2 + + will not match any rule and therefore is an invalid input.

3.1.5 Formal definitions for vocabulary and syntax

Vocabulary is usually expressed by regular expressions.

For example our language will be defined as:

figure8

As you see, integers are defined by a regular expression.

Syntax is usually defined in a format called BNF. Our language will be defined as:

figure9

We said that a language can be parsed by regular parsers if its grammar is a context free grammar. An intuitive definition of a context free grammar is a grammar that can be entirely expressed in BNF. For a formal definition see Wikipedia’s article on Context-free grammar

3.1.6 Types of parsers

There are two basic types of parsers – top down parsers and bottom up parsers. An intuitive explanation is that top down parsers see the high level structure of the syntax and try to match one of them. Bottom up parsers start with the input and gradually transform it into the syntax rules, starting from the low level rules until high level rules are met.

Let’s see how the two types of parsers will parse our example:

Top down parser will start from the higher level rule – it will identify 2 + 3 as an expression. It will then identify 2 + 3 – 1 as an expression (the process of identifying the expression evolves matching the other rules, but the start point is the highest level rule).

The bottom up parser will scan the input until a rule is matched it will then replace the matching input with the rule. This will go on until the end of the input. The partly matched expression is placed on the parsers stack.

figure10

This type of bottom up parser is called a shift-reduce parser, because the input is shifted to the right (imagine a pointer pointing first at the input start and moving to the right) and is gradually reduced to syntax rules.

3.1.7 Generating parsers automatically

There are tools that can generate a parser for you. They are called parser generators. You feed them with the grammar of your language—its vocabulary and syntax rules—and they generate a working parser. Creating a parser requires a deep understanding of parsing and its not easy to create an optimized parser by hand, so parser generators can be very useful.

Webkit uses two well known parser generators – Flex for creating a lexer and Bison for creating a parser (you might run into them with the names Lex and Yacc). Flex input is a file containing regular expression definitions of the tokens. Bison’s input is the language syntax rules in BNF format.

3.2 HTML Parser

HTML Parser는 HTML markup 구문을 Parser Tree로 변환 하는 것이다.

3.2.1 The HTML grammar definition

HTML의 어휘와 구문은 W3C에서 만든 specifications에 정의가 되어있다. 현재 버전은 HTML4이고 HTML5가 현재 진행 중이다.

3.2.2 Not a context free grammar

우리가 Parsing 소개에서 보아온 것처럼, 문법 구문은 BNF와 같은 포맷을 사용해서 정형적으로 정의되어 질 수 있었다. 그러나 안타깝게도

As we have seen in the parsing introduction, grammar syntax can be defined formally using formats like BNF.

Unfortunately all the conventional parser topics do not apply to HTML (I didn’t bring them up just for fun – they will be used in parsing CSS and JavaScript). HTML cannot easily be defined by a context free grammar that parsers need.

There is a formal format for defining HTML — DTD (Document Type Definition) — but it is not a context free grammar.

This appears strange at first sight; HTML is rather close to XML. There are lots of available XML parsers. There is an XML variation of HTML — XHTML — so what’s the big difference?

The difference is that HTML approach is more “forgiving”, it lets you omit certain tags which are added implicitly, sometimes omit the start or end of tags etc. On the whole it’s a “soft” syntax, as opposed to XML’s stiff and demanding syntax.

Apparently this seemingly small difference makes a world of a difference. On one hand this is the main reason why HTML is so popular – it forgives your mistakes and makes life easy for the web author. On the other hand, it makes it difficult to write a formal grammar. So to summarize – HTML cannot be parsed easily, not by conventional parsers since its grammar is not a context free grammar, and not by XML parsers.

3.2.3 HTML DTD

HTML definition is in a DTD format. This format is used to define languages of the SGMLfamily. The format contains definitions for all allowed elements, their attributes and hierarchy. As we saw earlier, the HTML DTD doesn’t form a context free grammar.

There are a few variations of the DTD. The strict mode conforms solely to the specifications but other modes contain support for markup used by browsers in the past. The purpose is backwards compatibility with older content. The current strict DTD is here:www.w3.org/TR/html4/strict.dtd

3.2.4 DOM

The output tree – the “parse tree” is a tree of DOM element and attribute nodes. DOM is short for Document Object Model. It is the object presentation of the HTML document and the interface of HTML elements to the outside world like JavaScript.
The root of the tree is the “Document” object.

The DOM has an almost one-to-one relation to the markup. For example, this markup:

figure11

Would be translated to the following DOM tree:

figure12

Like HTML, DOM is specified by the W3C organization. See www.w3.org/DOM/DOMTR. It is a generic specification for manipulating documents. A specific module describes HTML specific elements. The HTML definitions can be found here: www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-definitions.html.

When I say the tree contains DOM nodes, I mean the tree is constructed of elements that implement one of the DOM interfaces. Browsers use concrete implementations that have other attributes used by the browser internally.

3.2.5 The parsing algorithm

As we saw in the previous sections, HTML cannot be parsed using the regular top down or bottom up parsers.

The reasons are:

  1. The forgiving nature of the language.
  2. The fact that browsers have traditional error tolerance to support well known cases of invalid HTML.
  3. The parsing process in reentrant. Usually the source doesn’t change during parsing, but in HTML, script tags containing document.write can add extra tokens, so the parsing process actually modifies the input.

Unable to use the regular parsing techniques, browsers create custom parsers for parsing HTML.

The parsing algorithm is described in detail by the HTML5 specification. The algorithm consists of two stages – tokenization and tree construction.

Tokenization is the lexical analysis, parsing the input into tokens. Among HTML tokens are start tags, end tags, attribute names and attribute values.

The tokenizer recognizes the token, gives it to the tree constructor, and consumes the next character for recognizing the next token, and so on until the end of the input.

figure13

The tokenization algorithm

The algorithm’s output is an HTML token. The algorithm is expressed as a state machine. Each state consumes one or more characters of the input stream and updates the next state according to those characters. The decision is influenced by the current tokenization state and by the tree construction state. This means the same consumed character will yield different results for the correct next state, depending on the current state. The algorithm is too complex to describe fully, so let’s see a simple example that will help us understand the principle.

Basic example – tokenizing the following HTML:

figure14

The initial state is the “Data state”. When the < character is encountered, the state is changed to “Tag open state”. Consuming an a-z character causes creation of a “Start tag token”, the state is changed to “Tag name state”. We stay in this state until the >character is consumed. Each character is appended to the new token name. In our case the created token is an html token.

When the > tag is reached, the current token is emitted and the state changes back to the“Data state”. The  tag will be treated by the same steps. So far the html and bodytags were emitted. We are now back at the “Data state”. Consuming the H character ofHello world will cause creation and emitting of a character token, this goes on until the <of  is reached. We will emit a character token for each character of Hello world.

We are now back at the “Tag open state”. Consuming the next input / will cause creation of an end tag token and a move to the “Tag name state”. Again we stay in this state until we reach >.Then the new tag token will be emitted and we go back to the “Data state”. The  input will be treated like the previous case.

figure15

Tree construction algorithm

When the parser is created the Document object is created. During the tree construction stage the DOM tree with the Document in its root will be modified and elements will be added to it. Each node emitted by the tokenizer will be processed by the tree constructor. For each token the specification defines which DOM element is relevant to it and will be created for this token. Except of adding the element to the DOM tree it is also added to a stack of open elements. This stack is used to correct nesting mismatches and unclosed tags. The algorithm is also described as a state machine. The states are called “insertion modes”.

Let’s see the tree construction process for the example input:

figure16

The input to the tree construction stage is a sequence of tokens from the tokenization stage The first mode is the “initial mode”. Receiving the html token will cause a move to the“before html” mode and a reprocessing of the token in that mode. This will cause a creation of the HTMLHtmlElement element and it will be appended to the root Document object.

The state will be changed to “before head”. We receive the “body” token. An HTMLHeadElement will be created implicitly although we don’t have a “head” token and it will be added to the tree.

We now move to the “in head” mode and then to “after head”. The body token is reprocessed, an HTMLBodyElement is created and inserted and the mode is transferred to“in body”.

The character tokens of the “Hello world” string are now received. The first one will cause creation and insertion of a “Text” node and the other characters will be appended to that node.

The receiving of the body end token will cause a transfer to “after body” mode. We will now receive the html end tag which will move us to “after after body” mode. Receiving the end of file token will end the parsing.

figure17

Actions when the parsing is finished

At this stage the browser will mark the document as interactive and start parsing scripts that are in “deferred” mode – those who should be executed after the document is parsed. The document state will be then set to “complete” and a “load” event will be fired.

You can see the full algorithms for tokenization and tree construction in HTML5 specification

3.2.9Browsers’ error tolerance

You never get an “Invalid Syntax” error on an HTML page. Browsers fix any invalid content and go on.

Take this HTML for example:

figure18

I must have violated about a million rules (“mytag” is not a standard tag, wrong nesting of the “p” and “div” elements and more) but the browser still shows it correctly and doesn’t complain. So a lot of the parser code is fixing the HTML author mistakes.

The error handling is quite consistent in browsers but amazingly enough it’s not part of HTML current specification. Like bookmarking and back/forward buttons it’s just something that developed in browsers over the years. There are known invalid HTML constructs that repeat themselves in many sites and the browsers try to fix them in a conformant way with other browsers.

The HTML5 specification does define some of these requirements. Webkit summarizes this nicely in the comment at the beginning of the HTML parser class

figure23

Let’s see some Webkit error tolerance examples:

instead of

Some sites use instead of
. In order to be compatible with IE and Firefox, Webkit treats this like
.
The code:

figure19

A stray table

A stray table is a table inside another table contents but not inside a table cell.
Like this example:

figure20

Webkit will change the hierarchy to two sibling tables:

figure21

The code:

figure22

Webkit uses a stack for the current element contents – it will pop the inner table out of the outer table stack. The tables will now be siblings.

Nested form elements

In case the user puts a form inside another form, the second form is ignored.
The code:

figure24

A too deep tag hierarchy

The comment speaks for itself.

figure27

figure25

Misplaced html or body end tags

Again – the comment speaks for itself.

figure28

figure26

So web authors beware – unless you want to appear as an example in a Webkit error tolerance code snippet – write well formed HTML.

3.3 CSS parsing

Remember the parsing concepts in the introduction? Well, unlike HTML, CSS is a context free grammar and can be parsed using the types of parsers described in the introduction. In fact the CSS specification defines CSS lexical and syntax grammar.

Let’s see some examples:
The lexical grammar (vocabulary) is defined by regular expressions for each token:

comment   \/\*[^*]*\*+([^/*][^*]*\*+)*\/
num   [0-9]+|[0-9]*"."[0-9]+
nonascii  [\200-\377]
nmstart   [_a-z]|{nonascii}|{escape}
nmchar    [_a-z0-9-]|{nonascii}|{escape}
name    {nmchar}+
ident   {nmstart}{nmchar}*

“ident” is short for identifier, like a class name. “name” is an element id (that is referred by “#” )

The syntax grammar is described in BNF.

figure29

Explanation: A ruleset is this structure:

figure30

div.error and a.error are selectors. The part inside the curly braces contains the rules that are applied by this ruleset. This structure is defined formally in this definition:

figure31

This means a ruleset is a selector or optionally number of selectors separated by a coma and spaces (S stands for white space). A ruleset contains curly braces and inside them a declaration or optionally a number of declarations separated by a semicolon. “declaration” and “selector” will be defined in the following BNF definitions.

3.3.1Webkit CSS parser

Webkit uses Flex and Bison parser generators to create parsers automatically from the CSS grammar files. As you recall from the parser introduction, Bison creates a bottom up shift-reduce parser. Firefox uses a top down parser written manually. In both cases each CSS file is parsed into a StyleSheet object, each object contains CSS rules. The CSS rule objects contain selector and declaration objects and other object corresponding to CSS grammar.

figure32

The order of processing scripts and style sheets

3.4.1Scripts

The model of the web is synchronous. Authors expect scripts to be parsed and executed immediately when the parser reaches a

WebKit2 InjectedBundle

InjectedBundle은 WebKit2에서 새로 등장한 개념으로 WebProcess에 기존
방법으로 추가하기 어려운 기능을 plugin 처럼 startup 시간에 동적으로 라이브러리(by dlopen)를 로딩하여 해당하는 기능을 지원하는 것입니다.  Igalia의 Carlos 가  webkit-gtk 메일링리스트 쓴 글에 따르면 현재 WebKit2의 InjectedBundle은 일반적인 plugin 과 달리 오직 하나의 shared library 로드 만을 지원하고 있습니다. 현재 WebKit2 InjectedBundle은 DOM binding, intent, back/forward list 등을 지원하고 있습니다.

이 개념이 왜 WebKit2에 반영이 되었을까에 대해서 추측을 해보자면, WebKit2의 기본 구조에서 유추해 볼 수 있을 것 같습니다. 기본적으로 WebKit2 모델은 WebProcess와 UIProcess 로 이루어져 양 프로세스간의 IPC 통신으로 데이터를 주고 받고 있습니다. 이러다 보니 모든 기능을 구현하기 위해서는 proxy 를 만들고 서로 통신을 해야 하는데 이 경우 너무 불필요한 작업을 많이 해야한 경우가 발생하는 것이죠. 다시 말하면, InjectedBundle을 통해서 UIProcess를 통하지 않고서 third party 라이브러리와 WebProcess에 붙여서 플러그 인과 같은 기능을 제공해 줄 수 있습니다.

WebKit Contribution Overview

오늘은 WebKit 에 어떻게 Patch를 올리는 지에 대해서 얘기해 볼까 합니다. 위의 그림은 WebKit에 Patch를 올리면 어떻게 처리가 되는지를 보여주는 그림입니다. 먼저 개발자가 Patch를 작성을 한 후, WebKit Bugzilla에 Bug를 생성합니다. 그리고 나서 작성한 Patch를 Bug에 올리게 됩니다. 그러면, Bugzilla는 Patch를 리뷰 하기 전에 Coding Style 검증과 각 Port별  사전 Build 테스트를 합니다. 이것을 Bugzilla에서는 EWS(Early Warning System)라고 부릅니다.  즉, 기본적인 coding style 검증, build test를 Reviewer가 review를 하기 전에 Bot을 이용해서 자동화 한 것입니다.

기본적인 검증이 끝나면 Reviewer가 Patch를 리뷰를 합니다. Patch가 리뷰가 되어서 승인이 되면 Bugzilla는 승인된 패치를 Commit Queue에 추가하여 다시 한번 Build 테스트를 합니다. 이 경우는 모든 Port에서 하는 것이 아니고 mac과 chromium 포트만 합니다. Commit Queue를 통해서 Patch 가 Mainline에 반영이 되면 실시간으로 WebKit IRC의 #webkit 채널에 공지를 합니다. 그리고, Repository에 반영된 Patch는 WebKit Build Bot Master에 의해서 각 Port 별 Build Bot Slave에 패치를 보내지고,  다시 한번 Build 및 Regression 테스트를 합니다. 이 때 각 Port 에서 Build Break이 발생을 하면 최대한 빨리 Build Break를 수정해야 합니다. 보통 문제를 일으킨 Patch author가 수정을 하지만 author 가 수정을 하지 않으면 보통 메인테이너가 패치를 roll out을 합니다.

참고로, WebKit 에서는 코드 제출, 랜딩 그리고 roll out을 쉽게 할 수 있는 스크립트를 제공해 주고 있습니다. webkit-patch라는 스크립트인데요. 보통 Bugzilla 에 editbug permission을 가지고 계신 분은 이 스크립트를 사용하시면 패치 제출 전에 해야하는 changelog 작성, coding style checking 등을 자동으로 체크한 후 WebKit Bugzilla에 패치를 제출하게 됩니다.

– Tools/Scripts/webkit-patch upload