Building Chromium browser on your Mac

Copyright © Chromium Project

Building your own browser is the best way to find bugs and fix them. Now, I'd like to introduce how to build Chromium on your mac. I think that the latest code seems more stable(?) and provides more features.

This is a starting point to build Chromium on Mac OS X.
http://code.google.com/p/chromium/wiki/MacBuildInstructions

Installing the depot-tools

http://dev.chromium.org/developers/how-tos/install-gclient

$ svn co http://src.chromium.org/svn/trunk/tools/depot_tools

Add depot_tools to your PATH:
$ export PATH=`pwd`/depot_tools:"$PATH"

Getting the code

A checkout straight from the Subversion (SVN) repository can take a long time. It would be good to download a tar ball from http://build.chromium.org/buildbot/archives/chromium_tarball.html

Then, you can update the code to the latest revision from the SVN repository.
$ gclient sync

Building from the command line

To build all targets (it takes a long time due to test case builds)
$ cd ~/chromium/src/build
$ xcodebuild -project all.xcodeproj -configuration Debug -target All

To build just chrome:
$ cd ~/chromium/src/chrome
$ xcodebuild -project chrome.xcodeproj -configuration Debug -target chrome

Running Chromium

Run Chromium debug build
$ cd ~/chromium/src/xcodebuild/Debug

$ open ./Chromium.app

Run Chromium release build

$ cd ~/chromium/src/xcodebuild/Release

$ open ./Chromium.app

The latest revision of Chromium looks cool.

Feedbacks from the communities on the key events handling in WebKit

I posted an email to the WebKit mailing list on the issue I mentioned in the previous blog.The email introduced a status of the inconsistent event handling during a IME composition on WebKit. Fortunately, I've got quick feedbacks from the communities on each issue as follows,

Issue1) IME Composition events should be handled consistently in all ports of WebKit.
=> "This can't be achieved as it depends on the platform IME system. Therefore, different IMEs making consistent behaviors across multiple platforms is an exercise in futility. However, If we are seeing different behaviour with the same IME on a single platform, that's a bug."

Issue2) The textInput event should be dispatched after a compositionend event.
=> "There's a discussion on www-dom at w3.org about changing the spec because there seems a issue of handling a textInput event. Currently, before the textInput event is dispatched, DOM has been already mutated during a composition. Therefore, If there is to be a textInput event, first, the composition text is removed. And then, if the textEvent is not cancelled, the browser inserts the composition text again. It seems not efficient."

Issue3) While a composition session is active, keyboard events should not be dispatched to the DOM.
=> In relation to keyboard events, WebKit has fired key events during a composition for a long time. Therefore, It can't stop to fire key events in order to avoid site break.

As a result, they agreed that the DOM Level 3 event model for input composition does not match the requirements of actual web content as I have worried. Therefore, in order to avoid the confusion among web developers, the DOM Level3 events spec needs to introduce the reason why each browser handles keyboard events in different ways.